[要約] RFC 9286 は、RPKIにおける"マニフェスト"を定義し、リポジトリ内の署名済みオブジェクトのリストを含む署名されたオブジェクトである。マニフェストは、リポジトリ内の署名済みオブジェクトを検証し、リプレイ攻撃や不正な変更・削除を検知することを目的としている。
Internet Engineering Task Force (IETF) R. Austein
Request for Comments: 9286 Arrcus, Inc.
Obsoletes: 6486 G. Huston
Category: Standards Track APNIC
ISSN: 2070-1721 S. Kent
Independent
M. Lepinski
New College Florida
June 2022
Manifests for the Resource Public Key Infrastructure (RPKI)
リソース公開キーインフラストラクチャ（RPKI）のマニフェスト
Abstract
概要
This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486.
このドキュメントは、リソース公開キーインフラストラクチャ（RPKI）で使用する「マニフェスト」を定義しています。マニフェストは、リポジトリでの公開を担当する当局に関連付けられたリポジトリ公開ポイント（ディレクトリ）のすべての署名されたオブジェクト（ファイル）のリストを含む署名されたオブジェクト（ファイル）です。各証明書、証明書取消リスト（CRL）、またはこのリポジトリの公開ポイントで公開されている当局によって発行されたその他のタイプの署名されたオブジェクトについて、マニフェストには、ファイルのコンテンツのハッシュを含むファイルの名前の両方が含まれています。マニフェストは、頼る当事者（RP）がリポジトリに対する特定の形式の攻撃を検出できるようにすることを目的としています。具体的には、RPがリポジトリの公開ポイントから取得された署名されたオブジェクトに対してマニフェストの内容をチェックすると、RPはリプレイ攻撃、および署名されたオブジェクトの不正な変更または削除を検出できます。このドキュメントは、RFC 6486を廃止します。
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 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9286.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9286で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. Manifest Scope
3. Manifest Signing
4. Manifest Definition
4.1. eContentType
4.2. eContent
4.2.1. Manifest
4.2.2. Names in FileAndHash Objects
4.3. Content-Type Attribute
4.4. Manifest Validation
5. Manifest Generation
5.1. Manifest Generation Procedure
5.2. Considerations for Manifest Generation
6. Relying Party Processing of Manifests
6.1. Manifest Processing Overview
6.2. Acquiring a Manifest for a CA
6.3. Detecting Stale and/or Prematurely Issued Manifests
6.4. Acquiring Files Referenced by a Manifest
6.5. Matching File Names and Hashes
6.6. Failed Fetches
7. Publication Repositories
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. ASN.1 Module
Appendix B. Changes since RFC 6486
Acknowledgements
Authors' Addresses
The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of a distributed repository system [RFC6481] to make available a variety of objects needed by relying parties (RPs). Because all of the objects stored in the repository system are digitally signed by the entities that created them, attacks that modify these published objects are detectable by RPs. However, digital signatures alone provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not yet expired, but have since been superseded), or in-flight attacks that remove an object that should be present in the repository. To assist in the detection of such attacks, RPKI repository systems make use of a signed object called a "manifest".
リソース公開キーインフラストラクチャ（RPKI）[RFC6480]は、分散リポジトリシステム[RFC6481]を使用して、当事者（RP）に必要なさまざまなオブジェクトを利用できるようにします。リポジトリシステムに保存されているすべてのオブジェクトは、それらを作成したエンティティによってデジタル的に署名されているため、これらの公開されたオブジェクトを変更する攻撃はRPSによって検出可能です。ただし、デジタル署名だけでは、署名されたオブジェクトの「古い」バージョンを置き換える攻撃（つまり、まだ有効でまだ期限切れになっていないが、その後置換されたオブジェクト）、または飛行中のオブジェクトを削除するオブジェクトを削除する攻撃に対する保護を提供しません。リポジトリに存在します。このような攻撃の検出を支援するために、RPKIリポジトリシステムは「マニフェスト」と呼ばれる署名されたオブジェクトを使用します。
A manifest is a signed object that enumerates all the signed objects (files) in the repository publication point (directory) that are associated with an authority responsible for publishing at that publication point. Each manifest contains both the name of the file containing the object and a hash of the file content, for every signed object issued by an authority that is published at the authority's repository publication point. A manifest is intended to allow an RP to detect unauthorized object removal or the substitution of stale versions of objects at a publication point. A manifest also is intended to allow an RP to detect similar outcomes that may result from an on-path attack during the retrieval of objects from the repository. Manifests are intended to be used in Certification Authority (CA) publication points in repositories (directories containing files that are subordinate certificates and Certificate Revocation Lists (CRLs) issued by this CA and other signed objects that are verified by End-Entity (EE) certificates issued by this CA).
マニフェストは、その公開ポイントでの公開を担当する当局に関連付けられているリポジトリ公開ポイント（ディレクトリ）のすべての署名されたオブジェクト（ファイル）を列挙する署名されたオブジェクトです。各マニフェストには、オブジェクトを含むファイルの名前とファイルコンテンツのハッシュの両方が含まれています。マニフェストとは、RPが公開ポイントでオブジェクトの古いバージョンの代替または置換を許可されていないオブジェクトの削除を検出できるようにすることを目的としています。また、マニフェストは、RPがリポジトリからオブジェクトの検索中にパス上の攻撃から生じる可能性のある同様の結果を検出できるようにすることを目的としています。マニフェストは、このCAおよびエンドエンティティ（EE）証明書によって検証されている他の署名されたオブジェクトによって発行された、下位証明書および証明書の取り消しリスト（CRL）であるファイルを含むディレクトリを含むリポジトリの公認局（CA）の出版ポイントで使用することを目的としています。このCAによって発行）。
Manifests are modeled on CRLs, as the issues involved in detecting stale manifests and potential attacks using manifest replays, etc., are similar to those for CRLs. The syntax of the manifest payload differs from CRLs, since RPKI repositories contain objects not covered by CRLs, e.g., digitally signed objects, such as Route Origin Authorizations (ROAs) [RFC6482].
マニフェストはCRLでモデル化されています。これは、マニフェストリプレイなどを使用した古いマニフェストと潜在的な攻撃の検出に伴う問題は、CRLのものと同様です。RPKIリポジトリには、Route Origin Authorizations（ROAS）[RFC6482]などのデジタル署名されたオブジェクト、たとえばCRLでカバーされていないオブジェクトが含まれているため、マニフェストペイロードの構文はCRLとは異なります。
This document obsoletes [RFC6486].
この文書は廃止[RFC6486]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
A manifest associated with a CA's repository publication point contains a list of:
CAのリポジトリ公開ポイントに関連付けられたマニフェストには、次のリストが含まれています。
* the set of (non-expired, non-revoked) certificates issued and published by this CA,
* このCAによって発行および公開された証明書のセット、このCAによって発行されました。
* the most recent CRL issued by this CA, and
* このCAによって発行された最新のCRL、および
* all published signed objects that are verifiable using EE certificates [RFC6487] issued by this CA (other than the manifest itself).
* このCAによって発行されたEE証明書[RFC6487]を使用して検証可能なすべての公開された署名されたオブジェクト（マニフェスト自体以外）。
Every RPKI signed object includes, in the Cryptographic Message Syntax (CMS) [RFC5652] wrapper of the object, the EE certificate used to verify it [RFC6488]. Thus, there is no requirement to separately publish that EE certificate at the CA's repository publication point.
すべてのRPKI署名されたオブジェクトには、暗号化メッセージの構文（CMS）[RFC5652]オブジェクトのラッパー、それを検証するために使用されるEE証明書に含まれています[RFC6488]が含まれます。したがって、CAのリポジトリ公開ポイントでそのEE証明書を個別に公開する要件はありません。
Where multiple CA instances share a common publication point, as can occur when a CA performs a key-rollover operation [RFC6489], the repository publication point will contain multiple manifests. In this case, each manifest describes only the collection of published products of its associated CA instance.
複数のCAインスタンスが共通の公開ポイントを共有する場合、CAがキーロールオーバー操作[RFC6489]を実行したときに発生する可能性のあるように、リポジトリの公開ポイントには複数のマニフェストが含まれます。この場合、各マニフェストは、関連するCAインスタンスの公開された製品のコレクションのみを記述します。
A CA's manifest is verified using an EE certificate. The SubjectInfoAccess (SIA) field of this EE certificate contains the accessMethod Object Identifier (OID) of id-ad-signedObject.
CAのマニフェストは、EE証明書を使用して検証されます。このEE証明書のsubjectinfoaccess（SIA）フィールドには、id-ad-signedObjectのAccessMethodオブジェクト識別子（OID）が含まれています。
The CA MUST sign only one manifest with each generated private key and MUST generate a new key pair for each new version of the manifest. An associated EE certificate used in this fashion is termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]).
CAは、生成された各秘密鍵で1つのマニフェストのみに署名する必要があり、マニフェストの新しいバージョンごとに新しいキーペアを生成する必要があります。この方法で使用される関連EE証明書は、「1回限りの使用」EE証明書と呼ばれます（[RFC6487]のセクション3を参照）。
A manifest is an RPKI signed object, as specified in [RFC6488]. The RPKI signed object template requires specification of the following data elements in the context of the manifest structure.
マニフェストは、[RFC6488]で指定されているRPKI署名されたオブジェクトです。RPKI署名されたオブジェクトテンプレートには、マニフェスト構造のコンテキストで次のデータ要素を指定する必要があります。
The eContentType for a manifest is defined as id-ct-rpkiManifest and has the numerical OID of 1.2.840.113549.1.9.16.1.26.
マニフェストのecontentTypeはID-CT-RPKIMANIFESTとして定義され、1.2.840.113549.1.9.16.1.26の数値OIDがあります。
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
The content of a manifest is ASN.1 encoded using the Distinguished Encoding Rules (DER) [X.690]. The content of a manifest is defined as follows:
マニフェストの内容は、識別式エンコードルール（der）[x.690]を使用してエンコードされています。マニフェストの内容は、次のように定義されます。
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
The manifestNumber, thisUpdate, and nextUpdate fields are modeled after the corresponding fields in X.509 CRLs (see [RFC5280]). Analogous to CRLs, a manifest is nominally current until the time specified in nextUpdate or until a manifest is issued with a greater manifest number, whichever comes first.
ManifestNumber、thisupdate、およびnextupDateフィールドは、x.509 CRLの対応するフィールドをモデル化します（[RFC5280]を参照）。CRLSに類似して、マニフェストは、NextUpDateで指定される時間まで、またはマニフェストがより大きなマニフェスト数のいずれか最初の方で発行されるまで、名目上電流です。
Because a "one-time-use" EE certificate is employed to verify a manifest, the EE certificate MUST be issued with a validity period that coincides with the interval from thisUpdate to nextUpdate in the manifest, to prevent needless growth of the CA's CRL.
「1回限りの」EE証明書が採用されてマニフェストを検証するため、EE証明書は、CAのCRLの不必要な成長を防ぐために、マニフェストのYupdateからnextupdateまでの間隔と一致する有効期間で発行する必要があります。
The data elements of the manifest structure are defined as follows:
マニフェスト構造のデータ要素は、次のように定義されています。
version: The version number of this version of the manifest specification MUST be 0.
バージョン：マニフェスト仕様のこのバージョンのバージョン番号は0でなければなりません。
manifestNumber: This field is an integer that is incremented (by 1) each time a new manifest is issued for a given publication point. This field allows an RP to detect gaps in a sequence of published manifests.
ManifestNumber：このフィールドは、特定の出版ポイントに対して新しいマニフェストが発行されるたびに（1）増加する整数です。このフィールドにより、RPは公開された一連のマニフェストのギャップを検出できます。
As the manifest is modeled on the CRL specification, the manifestNumber is analogous to the CRLNumber, and the guidance in [RFC5280] for CRLNumber values is appropriate as to the range of number values that can be used for the manifestNumber. Manifest numbers can be expected to contain long integers. Manifest verifiers MUST be able to process number values up to 20 octets. Conforming manifest issuers MUST NOT use number values longer than 20 octets. The issuer MUST increase the value of this field monotonically for each newly generated manifest. Each RP MUST verify that a purported "new" manifest contains a higher manifestNumber than previously validated manifests. If the purported "new" manifest contains a manifestNumber value equal to or lower than manifestNumber values of previously validated manifests, the RP SHOULD use locally cached versions of objects, as described in Section 6.6.
マニフェストはCRL仕様をモデル化するため、マニフェストナンバーはCRLNumberに類似しており、CRLNumber値の[RFC5280]のガイダンスは、マニフェストナンバーに使用できる数値の範囲に適しています。マニフェスト数には長い整数が含まれることが期待できます。マニフェスト検証剤は、最大20オクテットまでの数値を処理できる必要があります。適合マニフェスト発行者は、20オクテットより長い数値を使用してはなりません。発行者は、新しく生成されたマニフェストごとに、このフィールドの価値を単調に増やす必要があります。各RPは、「新しい」マニフェストとされているとされていると、以前に検証されたマニフェストよりも高いマニフェストナンバーが含まれていることを確認する必要があります。「新しい」マニフェストとされる「新しい」マニフェストに、以前に検証されたマニフェストのマニフェストナンバー値以下のマニフェストナンバー値が含まれている場合、RPはセクション6.6で説明されているように、オブジェクトのローカルキャッシュバージョンを使用する必要があります。
thisUpdate: This field contains the time when the manifest was created. This field has the same format constraints as specified in [RFC5280] for the CRL field of the same name. The issuer MUST ensure that the value of this field is more recent than any previously generated manifest. Each RP MUST verify that this field value is greater (more recent) than the most recent manifest it has validated. If this field in a purported "new" manifest is smaller (less recent) than previously validated manifests, the RP SHOULD use locally cached versions of objects, as described in Section 6.6.
thisupdate：このフィールドには、マニフェストが作成された時間が含まれています。このフィールドには、同じ名前のCRLフィールドについて[RFC5280]で指定された形式の制約が同じです。発行者は、このフィールドの価値が以前に生成されたマニフェストよりも最近であることを確認する必要があります。各RPは、このフィールド値が検証した最新のマニフェストよりも大きいことを確認する必要があります。「新しい」マニフェストとされるこのフィールドが、以前に検証されたマニフェストよりも小さい（最新のものではない）場合、RPはセクション6.6で説明されているように、オブジェクトのローカルでキャッシュされたバージョンを使用する必要があります。
nextUpdate: This field contains the time at which the next scheduled manifest will be issued. The value of nextUpdate MUST be later than the value of thisUpdate. The specification of the GeneralizedTime value is the same as required for the thisUpdate field.
NextUpDate：このフィールドには、次のスケジュールされたマニフェストが発行される時間が含まれています。nextupdateの値は、thisupdateの値よりも遅い必要があります。一般化された時間値の仕様は、ThisUpDateフィールドに必要なものと同じです。
If the authority alters any of the items that it has published in the repository publication point, then the authority MUST issue a new manifest. Even if no changes are made to objects at a publication point, a new manifest MUST be issued before the nextUpdate time. Each manifest encompasses a CRL, and the nextUpdate field of the manifest SHOULD match that of the CRL's nextUpdate field, as the manifest will be reissued when a new CRL is published. When a new manifest is issued before the time specified in nextUpdate of the current manifest, the CA MUST also issue a new CRL that revokes the EE certificate corresponding to the old manifest.
当局がリポジトリの公開ポイントで公開した項目のいずれかを変更する場合、当局は新しいマニフェストを発行する必要があります。出版ポイントでオブジェクトに変更が加えられない場合でも、NextUpDateの時間前に新しいマニフェストを発行する必要があります。各マニフェストにはCRLが含まれ、マニフェストの次のフィールドは、新しいCRLが公開されるとマニフェストが再発行されるため、CRLのnextupdateフィールドのフィールドと一致する必要があります。現在のマニフェストのNextupDateで指定された時間の前に新しいマニフェストが発行された場合、CAは古いマニフェストに対応するEE証明書を取り消す新しいCRLも発行する必要があります。
fileHashAlg: This field contains the OID of the hash algorithm used to hash the files that the authority has placed into the repository. The hash algorithm used MUST conform to the RPKI Algorithms and Key Size Profile specification [RFC7935].
FileHashalg：このフィールドには、当局がリポジトリに配置したファイルをハッシュするために使用されるハッシュアルゴリズムのOIDが含まれています。使用されるハッシュアルゴリズムは、RPKIアルゴリズムとキーサイズプロファイル仕様[RFC7935]に準拠する必要があります。
fileList: This field is a sequence of FileAndHash objects. There is one FileAndHash entry for each currently valid signed object that has been published by the authority (at this publication point). Each FileAndHash is an ordered pair consisting of the name of the file in the repository publication point (directory) that contains the object in question and a hash of the file's contents.
フィルリスト：このフィールドは、Fileandhashオブジェクトのシーケンスです。当局によって公開されている現在有効な署名されたオブジェクトごとに1つのFileandhashエントリがあります（この出版ポイント）。各fileandhashは、問題のオブジェクトとファイルの内容のハッシュを含むリポジトリ公開ポイント（ディレクトリ）のファイルの名前で構成される順序付けられたペアです。
Names that appear in the fileList MUST consist of one or more characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _ (UNDERSCORE), followed by a single . (DOT), followed by a three-letter extension. The extension MUST be one of those enumerated in the "RPKI Repository Name Schemes" registry maintained by IANA [IANA-NAMING].
フィルリストに表示される名前は、セットA-Z、A-Z、0-9、 - （ハイフン）、または_（アンダースコア）から選択された1つ以上の文字で構成され、その後にシングルが続く必要があります。（ドット）、3文字の拡張機能が続きます。拡張機能は、IANA [Iana-Naming]によって維持されている「RPKIリポジトリ名スキーム」レジストリに列挙されているものの1つでなければなりません。
As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid file name.
例として、「VixxBTS_TVXQ-2PMGOT7.cer」は有効なファイル名です。
The example above contains a mix of uppercase and lowercase characters in the file name. CAs and RPs MUST be able to perform filesystem operations in a case-sensitive, case-preserving manner.
上記の例には、ファイル名に大文字と小文字の文字が混在しています。CASとRPSは、ケースに敏感なケースプレゼンティング方法でファイルシステム操作を実行できる必要があります。
The mandatory content-type attribute MUST have its attrValues field set to the same OID as eContentType. This OID is id-ct-rpkiManifest and has the numerical value of 1.2.840.113549.1.9.16.1.26.
必須のコンテンツタイプの属性は、econtentTypeと同じOIDにAttrvaluesフィールドを設定する必要があります。このOIDはID-CT-RPKIMANIFESTであり、1.2.840.113549.1.9.16.1.26の数値を持っています。
To determine whether a manifest is valid, the RP MUST perform the following checks in addition to those specified in [RFC6488]:
マニフェストが有効かどうかを判断するには、RPは[RFC6488]で指定されたものに加えて、次のチェックを実行する必要があります。
1. The eContentType in the EncapsulatedContentInfo is id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).
1. contulatedContentInfoのecontentTypeは、ID-AD-RPKIMANIFESTです（OID 1.2.840.113549.1.9.16.1.16.1.26）。
2. The version of the rpkiManifest is 0.
2. rpkimanifestのバージョンは0です。
3. In the rpkiManifest, thisUpdate precedes nextUpdate.
3. rpkimanifestでは、このupdateはnextupdateに先行します。
Note: Although the thisUpdate and nextUpdate fields in the manifest eContent MUST match the corresponding fields in the CRL associated with the manifest, RPs MUST NOT reject a manifest solely because these fields are not identical.
注：マニフェストエコネントのこのupdateおよびnextupdateフィールドは、マニフェストに関連付けられたCRLの対応するフィールドと一致する必要がありますが、RPSはこれらのフィールドが同一ではないためにマニフェストを拒否してはなりません。
If the above procedure indicates that the manifest is invalid, then the manifest MUST be discarded and treated as though no manifest were present.
上記の手順がマニフェストが無効であることを示している場合、マニフェストは廃棄され、マニフェストが存在しないかのように扱わなければなりません。
For a CA publication point in the RPKI repository system, a CA MUST perform the following steps to generate a manifest:
RPKIリポジトリシステムのCA出版ポイントの場合、CAはマニフェストを生成するために次の手順を実行する必要があります。
1. Generate a new key pair for use in a "one-time-use" EE certificate.
1. 「1回限りの」EE証明書で使用する新しいキーペアを生成します。
2. Issue an EE certificate for this key pair. The CA MUST revoke the EE certificate used for the manifest being replaced.
2. このキーペアのEE証明書を発行します。CAは、マニフェストが交換されるために使用されるEE証明書を取り消す必要があります。
This EE certificate MUST have an SIA extension access description field with an accessMethod OID value of id-ad-signedObject, where the associated accessLocation references the publication point of the manifest as an object URL. (RPs are required to verify both of these syntactic constraints.)
このEE証明書には、AccessMethod oid oid値を備えたSIA拡張機能アクセス説明フィールドが必要です。関連するAccesslocationは、マニフェストの公開ポイントをオブジェクトURLとして参照しています。（これらの構文制約の両方を検証するには、RPSが必要です。）
This EE certificate MUST describe its Internet Number Resources (INRs) using the "inherit" attribute, rather than an explicit description of a resource set (see [RFC3779]). (RPs are required to verify this.)
このEE証明書は、リソースセットの明示的な説明ではなく、「継承」属性を使用して、インターネット番号リソース（INR）を記述する必要があります（[RFC3779]を参照）。（これを確認するにはRPSが必要です。）
The validity interval of the EE certificate MUST exactly match the thisUpdate and nextUpdate times specified in the manifest's eContent. (An RP MUST NOT consider misalignment of the validity interval in and of itself to be an error.)
EE証明書の有効性間隔は、Manifestのecontentで指定されたThisUpdateおよびNextupDate時間と正確に一致する必要があります。（RPは、妥当性間隔の不整合自体がエラーであると考えてはなりません。）
3. The EE certificate MUST NOT be published in the authority's repository publication point.
3. EE証明書は、当局のリポジトリ公開ポイントに公開されてはなりません。
4. Construct the manifest content.
4. マニフェストコンテンツを構築します。
The manifest content is described in Section 4.2.1. The manifest's fileList includes the file name and hash pair for each object issued by this CA that has been published at this repository publication point (directory). The collection of objects to be included in the manifest includes all certificates issued by this CA that are published at the CA's repository publication point, the most recent CRL issued by the CA, and all objects verified by EE certificates that were issued by this CA that are published at this repository publication point. (Sections 6.1 through 6.5 describe the checks that an RP MUST perform in support of the manifest content noted here.)
マニフェストコンテンツは、セクション4.2.1で説明されています。マニフェストのファイルリストには、このリポジトリの出版ポイント（ディレクトリ）で公開されているこのCAによって発行された各オブジェクトのファイル名とハッシュペアが含まれています。マニフェストに含まれるオブジェクトのコレクションには、CAのリポジトリ公開ポイントで公開されているこのCAが発行したすべての証明書、CAが発行した最新のCRL、およびこのCAによって発行されたEE証明書によって検証されたすべてのオブジェクトが含まれます。このリポジトリの公開ポイントで公開されています。（セクション6.1〜6.5は、RPがここに記載されているマニフェストコンテンツをサポートするために実行しなければならないチェックについて説明します。）
Note that the manifest does not include a self reference (i.e., its own file name and hash), since it would be impossible to compute the hash of the manifest itself prior to it being signed.
マニフェストには、署名される前にマニフェスト自体のハッシュを計算することは不可能であるため、自己参照（つまり、独自のファイル名とハッシュ）は含まれていないことに注意してください。
5. Encapsulate the manifest content using the CMS SignedData content type (as specified in Section 4), sign the manifest using the private key corresponding to the subject key contained in the EE certificate, and publish the manifest in the repository system publication point that is described by the manifest. (RPs are required to verify the CMS signature.)
5. CMS SignedDataコンテンツタイプ（セクション4で指定）を使用してマニフェストコンテンツをカプセル化し、EE証明書に含まれる主題キーに対応する秘密鍵を使用してマニフェストに署名し、説明されているリポジトリシステムの公開ポイントにマニフェストを公開しますマニフェスト。（CMS署名を確認するには、RPSが必要です。）
6. Because the key pair is to be used only once, the private key associated with this key pair MUST now be destroyed.
6. キーペアは一度だけ使用することであるため、このキーペアに関連付けられている秘密鍵を破壊する必要があります。
A new manifest MUST be issued and published before the nextUpdate time.
新しいマニフェストを発行して公開する必要があります。
An authority MUST issue a new manifest in conjunction with the finalization of changes made to objects in the publication point. If any named objects in the publication point are replaced, the authority MUST ensure that the file hash for each replaced object is updated accordingly in the new manifest. Additionally, the authority MUST revoke the certificate associated with each replaced object (other than a CRL), if it is not expired. 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 MUST implement some form of repository update procedure that mitigates, to the extent possible, the risk that RPs that are performing retrieval operations on the repository are exposed to inconsistent, transient, intermediate states during updates to the repository publication point (directory) and the associated manifest.
当局は、出版ポイントのオブジェクトに加えられた変更の最終化と併せて新しいマニフェストを発行する必要があります。公開ポイント内の名前のオブジェクトが置き換えられた場合、当局は、新しいマニフェストでそれに応じて、交換された各オブジェクトのファイルハッシュが更新されることを確認する必要があります。さらに、当局は、有効期限が切れない場合は、交換された各オブジェクト（CRL以外）に関連付けられた証明書を取り消す必要があります。当局は、この変更の範囲内ですべての操作をカバーする単一のマニフェストを発行する前に、リポジトリ変更の範囲内で公開リポジトリ上で多くのオブジェクト操作を実行する場合があります。リポジトリオペレーターは、可能な限り、リポジトリで検索操作を実行しているRPSが、リポジトリの公開ポイント（ディレクトリ）および更新中に一貫性のない一時的な中間状態にさらされるリスクを緩和するリポジトリ更新手順を実装する必要があります。関連するマニフェスト。
Since the manifest object URL is included in the SIA of issued certificates, a new manifest MUST NOT invalidate the manifest object URL of previously issued certificates. This implies that the manifest's publication name in the repository, in the form of an object URL, is unchanged across manifest generation cycles.
マニフェストオブジェクトURLは発行された証明書のSIAに含まれているため、新しいマニフェストは、以前に発行された証明書のマニフェストオブジェクトURLを無効にしてはなりません。これは、オブジェクトURLの形式のリポジトリ内のマニフェストの出版名が、マニフェストの世代サイクル全体で変化しないことを意味します。
When a CA entity is performing a key rollover, the entity MAY choose to have two CA instances simultaneously publishing into the same repository publication point. In this case, there will be one manifest associated with each active CA instance that is publishing into the common repository publication point (directory).
CAエンティティがキーロールオーバーを実行している場合、エンティティは同じリポジトリの公開ポイントに同時に公開される2つのCAインスタンスを使用することを選択できます。この場合、一般的なリポジトリの公開ポイント（ディレクトリ）に公開している各アクティブなCAインスタンスに関連付けられた1つのマニフェストがあります。
Each RP MUST use the current manifest of a CA to control addition of listed files to the set of signed objects the RP employs for validating basic RPKI objects: certificates, ROAs, and CRLs. Any files not listed on the manifest MUST NOT be used for validation of these objects. However, files not listed on a manifest MAY be employed to validate other signed objects, if the profile of the object type explicitly states that such behavior is allowed (or required). Note that relying on files not listed in a manifest may allow an attacker to effect substitution attacks against such objects.
各RPは、CAの現在のマニフェストを使用して、RPが基本的なRPKIオブジェクト（証明書、ROA、およびCRLSの検証に使用する署名されたオブジェクトのセットへのリストされたファイルの追加を制御する必要があります。マニフェストにリストされていないファイルは、これらのオブジェクトの検証に使用してはなりません。ただし、マニフェストにリストされていないファイルを使用して、オブジェクトタイプのプロファイルがそのような動作が許可されている（または必須）と明示的に述べている場合、他の署名されたオブジェクトを検証するために使用される場合があります。マニフェストにリストされていないファイルに依存すると、攻撃者がそのようなオブジェクトに対する代替攻撃を行うことができることに注意してください。
As noted earlier, manifests are designed to allow an RP to detect manipulation of repository data, errors by a CA or repository manager, and/or active attacks on the communication channel between an RP and a repository. Unless all of the files enumerated in a manifest can be obtained by an RP during a fetch operation, the fetch is considered to have failed and the RP MUST retry the fetch later.
前述のように、マニフェストは、RPがリポジトリデータの操作、CAまたはリポジトリマネージャーによるエラー、および/またはRPとリポジトリの間の通信チャネルへのアクティブな攻撃を検出できるように設計されています。マニフェストで列挙されているすべてのファイルがフェッチ操作中にRPによって取得できない限り、フェッチは失敗したと見なされ、RPは後でフェッチを再試行する必要があります。
[RFC6480] suggests (but does not mandate) that the RPKI model employ fetches that are incremental, e.g., an RP transfers files from a publication point only if they are new/changed since the previous, successful fetch represented in the RP's local cache. This document avoids language that relies on details of the underlying file transfer mechanism employed by an RP and a publication point to effect this operation. Thus, the term "fetch" refers to an operation that attempts to acquire the full set of files at a publication point, consistent with the id-ad-rpkiManifest URI extracted from a CA certificate's SIA (see below).
[RFC6480]は、RPKIモデルがインクリメンタルなフェッチを使用することを示唆しています（ただし、義務付けられていません）。このドキュメントは、この操作を実施するためにRPと出版ポイントで採用されている基礎となるファイル転送メカニズムの詳細に依存する言語を避けます。したがって、「Fetch」という用語は、CA証明書のSIAから抽出されたID-AD-RPKIMANIFEST URIと一致して、公開ポイントでファイルの完全なセットを取得しようとする操作を指します（以下を参照）。
If a fetch fails, it is assumed that a subsequent fetch will resolve problems encountered during the fetch. Until such time as a successful fetch is executed, an RP SHOULD use cached data from a previous, successful fetch. This response is intended to prevent an RP from misinterpreting data associated with a publication point and thus possibly treating invalid routes as valid, or vice versa.
フェッチが失敗した場合、後続のフェッチがフェッチ中に発生した問題を解決すると想定されます。成功したフェッチが実行されるまで、RPは以前の成功したフェッチのキャッシュデータを使用する必要があります。この応答は、RPが公開ポイントに関連するデータの誤解を誤って解釈することを防ぐことを目的としています。
The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to acquire the same set of validated repository files. It does not ensure that the RPs will achieve the same results with regard to validation of RPKI data, since that depends on how each RP resolves any conflicts that may arise in processing the retrieved files. Moreover, in operation, different RPs will access repositories at different times, and some RPs may experience local cache failures, so there is no guarantee that all RPs will achieve the same results with regard to acquisition or validation of RPKI data.
以下で説明する処理は、同じローカルキャッシュとRPKIリポジトリデータにアクセスできるすべてのRPSを引き起こすように設計されています。RPSがRPKIデータの検証に関して同じ結果を達成することは保証されません。これは、各RPが取得されたファイルの処理で発生する可能性のある競合を解決する方法に依存するためです。さらに、動作中、異なるRPSは異なる時間にリポジトリにアクセスし、一部のRPSはローカルキャッシュの障害を発生させる可能性があるため、すべてのRPがRPKIデータの取得または検証に関して同じ結果を達成するという保証はありません。
Note also that there is a "chicken and egg" relationship between the manifest and the CRL for a given CA instance. If the EE certificate for the current manifest is revoked, i.e., it appears in the current CRL, then the CA or publication point manager has made a serious error. In this case, the fetch has failed; proceed to Section 6.6. Similarly, if the CRL is not listed on a valid, current manifest, acquired during a fetch, the fetch has failed; proceed to Section 6.6, because the CRL is considered missing.
また、特定のCAインスタンスには、マニフェストとCRLの間に「鶏と卵」の関係があることに注意してください。現在のマニフェストのEE証明書が取り消された場合、つまり現在のCRLに表示される場合、CAまたはPublication Point Managerは重大なエラーを犯しました。この場合、フェッチは失敗しました。セクション6.6に進みます。同様に、CRLがフェッチ中に取得された有効な現在のマニフェストにリストされていない場合、フェッチは失敗しました。CRLが欠落していると見なされるため、セクション6.6に進みます。
For a given publication point, an RP MUST perform a series of tests to determine which signed object files at the publication point are acceptable. The tests described below (Sections 6.2 through 6.5) are to be performed using the manifest identified by the id-ad-rpkiManifest URI extracted from a CA certificate's SIA. All of the files referenced by the manifest MUST be located at the publication point specified by the id-ad-caRepository URI from the (same) CA certificate's SIA. The manifest and the files it references MUST reside at the same publication point. If an RP encounters any files that appear on a manifest but do not reside at the same publication point as the manifest, the RP MUST treat the fetch as failed, and a warning MUST be issued (see Section 6.6 below).
特定の公開ポイントでは、RPは一連のテストを実行して、公開ポイントでどの署名されたオブジェクトファイルが許容できるかを判断する必要があります。以下に説明するテスト（セクション6.2〜6.5）は、CA証明書のSIAから抽出されたID-AD-RPKIMANIFEST URIによって識別されたマニフェストを使用して実行されます。マニフェストによって参照されるすべてのファイルは、（同じ）CA証明書のSIAのID-AD-CarePository URIによって指定された公開ポイントに配置する必要があります。マニフェストとそれが参照するファイルは、同じ出版ポイントに存在する必要があります。RPがマニフェストに表示されているがマニフェストと同じ公開ポイントに存在しないファイルに遭遇する場合、RPはフェッチを失敗したと扱う必要があり、警告を発行する必要があります（以下のセクション6.6を参照）。
Note that, during CA key rollover [RFC6489], signed objects for two or more different CA instances will appear at the same publication point. Manifest processing is to be performed separately for each CA instance, guided by the SIA id-ad-rpkiManifest URI in each CA certificate.
CAキーロールオーバー[RFC6489]では、2つ以上の異なるCAインスタンスの署名されたオブジェクトが同じ公開ポイントに表示されることに注意してください。マニフェスト処理は、各CAインスタンスごとに個別に実行され、各CA証明書のSIA ID-AD-RPKIMANIFEST URIに導かれます。
The RP MUST fetch the manifest identified by the SIA id-ad-rpkiManifest URI in the CA certificate. If an RP cannot retrieve a manifest using this URI or if the manifest is not valid (Section 4.4), an RP MUST treat this as a failed fetch; proceed to Section 6.6. Otherwise, proceed to Section 6.3.
RPは、CA証明書にSIA ID-AD-RPKIMANIFEST URIによって識別されたマニフェストを取得する必要があります。RPがこのURIを使用してマニフェストを取得できない場合、またはマニフェストが有効でない場合（セクション4.4）、RPはこれを失敗したフェッチとして扱う必要があります。セクション6.6に進みます。それ以外の場合は、セクション6.3に進みます。
The RP MUST check that the current time (translated to UTC) is between thisUpdate and nextUpdate. If the current time lies within this interval, proceed to Section 6.4. If the current time is earlier than thisUpdate, the CA may have made an error or the RP's local notion of time may be in error. The RP MUST treat this as a failed fetch; proceed to Section 6.6. If the current time is later than nextUpdate, then the manifest is stale; the RP MUST treat this as a failed fetch. Proceed to Section 6.6. Otherwise, proceed to Section 6.4.
RPは、現在の時刻（UTCに翻訳されている）がThisupdateとnextupdateの間にあることを確認する必要があります。現在の時間がこの間隔内にある場合は、セクション6.4に進みます。現在の時刻がこれより早い場合、CAがエラーを犯したか、RPの現地の時間概念が誤っている可能性があります。RPはこれを失敗したフェッチとして扱う必要があります。セクション6.6に進みます。現在の時刻がnextupdateよりも遅い場合、マニフェストは古くなっています。RPはこれを失敗したフェッチとして扱う必要があります。セクション6.6に進みます。それ以外の場合は、セクション6.4に進みます。
The RP MUST acquire all of the files enumerated in the manifest (fileList) from the publication point. If there are files listed in the manifest that cannot be retrieved from the publication point, the RP MUST treat this as a failed fetch. Proceed to Section 6.6. Otherwise, proceed to Section 6.5.
RPは、出版ポイントからマニフェスト（Filelist）に列挙されたすべてのファイルを取得する必要があります。出版ポイントから取得できないマニフェストにリストされているファイルがある場合、RPはこれを失敗したフェッチとして扱う必要があります。セクション6.6に進みます。それ以外の場合は、セクション6.5に進みます。
The RP MUST verify that the hash value of each file listed in the manifest matches the value obtained by hashing the file acquired from the publication point. If the computed hash value of a file listed on the manifest does not match the hash value contained in the manifest, then the fetch has failed, and the RP MUST respond accordingly. Proceed to Section 6.6.
RPは、マニフェストにリストされている各ファイルのハッシュ値が、公開ポイントから取得したファイルをハッシュすることによって得られる値と一致することを確認する必要があります。マニフェストにリストされているファイルの計算されたハッシュ値がマニフェストに含まれるハッシュ値と一致しない場合、フェッチは失敗し、RPはそれに応じて応答する必要があります。セクション6.6に進みます。
If a fetch fails for any of the reasons cited in Sections 6.2 through 6.5, the RP MUST issue a warning indicating the reason(s) for termination of processing with regard to this CA instance. It is RECOMMENDED that a human operator be notified of this warning.
セクション6.2から6.5で引用されている理由のいずれかでフェッチが失敗した場合、RPは、このCAインスタンスに関して処理の終了の理由を示す警告を発行する必要があります。人間のオペレーターにこの警告を通知することをお勧めします。
Termination of processing means that the RP SHOULD continue to use cached versions of the objects associated with this CA instance, until such time as they become stale or they can be replaced by objects from a successful fetch. This implies that the RP MUST NOT try to acquire and validate subordinate signed objects, e.g., subordinate CA certificates, until the next interval when the RP is scheduled to fetch and process data for this CA instance.
処理の終了とは、RPがこのCAインスタンスに関連付けられたオブジェクトのキャッシュバージョンを引き続き使用する必要があることを意味します。これは、RPがこのCAインスタンスのデータを取得して処理する予定の次の間隔まで、RPが下位署名されたオブジェクト、たとえば下位CA証明書を取得および検証しようとしてはならないことを意味します。
The RPKI publication system model requires that every publication point be associated with one or more CAs and be non-empty. Upon creation of the publication point associated with a CA, the CA MUST create and publish a manifest as well as a CRL. A CA's manifest will always contain at least one entry, i.e., a CRL issued by the CA [RFC6481], corresponding to the scope of this manifest.
RPKI出版システムモデルでは、すべての出版ポイントが1つ以上のCAに関連付けられ、空でないことが必要です。CAに関連付けられた出版ポイントが作成されると、CAはCRLと同様にマニフェストを作成および公開する必要があります。CAのマニフェストには、常に少なくとも1つのエントリ、つまり、このマニフェストの範囲に対応するCA [RFC6481]によって発行されたCRLが含まれます。
Every published signed object in the RPKI [RFC6488] is published in the repository publication point of the CA that issued the EE certificate, and is listed in the manifest associated with that CA certificate.
RPKI [RFC6488]で公開されたすべての署名されたオブジェクトは、EE証明書を発行したCAのリポジトリ出版ポイントに公開され、そのCA証明書に関連付けられたマニフェストにリストされています。
Manifests provide an additional level of protection for RPKI RPs. Manifests can assist an RP in determining if a repository object has been deleted, occluded, or otherwise removed from view, or if a publication of a newer version of an object has been suppressed (and an older version of the object has been substituted).
マニフェストは、RPKI RPSの追加レベルの保護を提供します。マニフェストは、RPがリポジトリオブジェクトが削除、閉塞、またはその他の方法で削除されたかどうかを判断するのを支援できます。または、新しいバージョンのオブジェクトの公開が抑制されているかどうか（およびオブジェクトの古いバージョンが置換されました）。
Manifests cannot repair the effects of such forms of corruption of repository retrieval operations. However, a manifest enables an RP to determine if a locally maintained copy of a repository is a complete and up-to-date copy, even when the repository retrieval operation is conducted over an insecure channel. In cases where the manifest and the retrieved repository contents differ, the manifest can assist in determining which repository objects form the difference set in terms of missing, extraneous, or superseded objects.
マニフェストは、リポジトリ検索操作のこのような形式の腐敗の影響を修復することはできません。ただし、マニフェストにより、RPは、リポジトリの取得操作が安全でないチャネルで行われた場合でも、リポジトリのローカルで維持されたコピーが完全かつ最新のコピーであるかどうかを判断できます。マニフェストと取得されたリポジトリの内容が異なる場合、マニフェストは、欠落、外部、または置換オブジェクトの観点から設定された差を形成するリポジトリオブジェクトを決定するのに役立ちます。
The signing structure of a manifest and the use of the nextUpdate value allow an RP to determine if the manifest itself is the subject of attempted alteration. The requirement for every repository publication point to contain at least one manifest allows an RP to determine if the manifest itself has been occluded from view. Such attacks against the manifest are detectable within the time frame of the regular schedule of manifest updates. Forms of replay attacks within finer-grained time frames are not necessarily detectable by the manifest structure.
マニフェストの署名構造とNextUpDate値の使用により、RPはマニフェスト自体が変更された変更の対象であるかどうかを判断することができます。すべてのリポジトリの出版物が少なくとも1つのマニフェストを含むことをポイントすることにより、RPはマニフェスト自体がビューから閉塞されているかどうかを判断できます。マニフェストに対するこのような攻撃は、マニフェストの更新の通常のスケジュールの時間枠内で検出可能です。より細かい粒度の時間枠内のリプレイ攻撃の形式は、マニフェスト構造によって必ずしも検出可能ではありません。
The "RPKI Signed Objects" registry was originally created and populated by [RFC6488]. The "RPKI Repository Name Schemes" registry was created by [RFC6481] and created four of the initial three-letter file name extensions. IANA has updated the reference for the "Manifest" row in the "RPKI Signed Objects" registry to point to this document.
「RPKI署名されたオブジェクト」レジストリは、もともと[RFC6488]によって作成され、入力されました。「RPKIリポジトリ名スキーム」レジストリは[RFC6481]によって作成され、最初の3文字のファイル名拡張機能のうち4つを作成しました。IANAは、「RPKI署名されたオブジェクト」レジストリの「マニフェスト」行の参照を更新して、このドキュメントを指しています。
IANA has also updated the following entries to refer to this document instead of RFC 6486:
IANAは、RFC 6486の代わりにこのドキュメントを参照するために、次のエントリを更新しました。
* id-mod-rpkiManifest (60) in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry
* 「S/MIMEモジュール識別子のSMIセキュリティ（1.2.840.113549.1.9.16.0）」のid-mod-rpkimanifest（60）」
* id-ct-rpkiManifest (26) in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry
* 「S/MIME CMSコンテンツタイプ（1.2.840.113549.1.9.16.1）」の「SMIセキュリティのSMIセキュリティ（1.2.840.113549.1.9.16.1）」
* the "Security considerations" entry in the application media type registration for rpki-manifest
* RPKi-Manifestのアプリケーションメディアタイプの登録への「セキュリティ上の考慮事項」エントリ
No other actions are required.
他のアクションは必要ありません。
[IANA-NAMING] IANA, "RPKI Repository Name Schemes", <https://www.iana.org/assignments/rpki/>.
[iana-naming] iana、 "rpkiリポジトリ名スキーム"、<https://www.iana.org/assignments/rpki/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509 Public Key Infrastructure Certificate and Certificate Recocation List（CRL）プロファイル"、RFC 5280、DOI 10.17487/RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.
[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、DOI 10.17487/RFC6481、2012年2月、<https：//www.rfc-editor。org/info/rfc6481>。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「ルートオリジナル認可（ROA）のプロファイル」、RFC 6482、DOI 10.17487/RFC6482、2012年2月、<https：//www.rfc-editor.org/info/rfc6482>。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487] Huston、G.、Michaelson、G.、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、DOI 10.17487/RFC6487、2012年2月、<https：//www.rfc-editor.org/info/rfc6487>。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <https://www.rfc-editor.org/info/rfc6488>.
[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「リソース公開キーインフラストラクチャ（RPKI）の署名されたオブジェクトテンプレート」、RFC 6488、DOI 10.17487/RFC6488、2012年2月、<https：//.rfc-editor.org/info/rfc6488>。
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>.
[RFC7935] Huston、G。およびG. Michaelson、ed。、「リソース公開キーインフラストラクチャで使用するアルゴリズムとキーサイズのプロファイル」、RFC 7935、DOI 10.17487/RFC7935、2016年8月、<https：//.rfc-editor.org/info/rfc7935>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[X.690] International Telecommunication Union, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, February 2021, <https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
[x.690]国際通信連合、「情報技術-ASN.1エンコードルール：基本エンコードルール（BER）、標準エンコードルール（CER）、識別済みエンコードルール（DER）の仕様」、ITU -T推奨X.690、2021年2月、<https://www.itu.int/rec/t-rec-x.690-202102-i/en>。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.
[RFC3779] Lynn、C.、Kent、S。、およびK. Seo、「IPアドレスおよび識別子のX.509拡張剤」、RFC 3779、DOI 10.17487/RFC3779、2004年6月、<https：//www.rfcc-editor.org/info/rfc3779>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、DOI 10.17487/RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487/RFC6480、2012年2月、<https://www.rfc-editor.org/info/rfc6480>。
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>.
[RFC6486] Austein、R.、Huston、G.、Kent、S。、およびM. Lepinski、「リソース公開キーインフラストラクチャ（RPKI）のマニフェスト」、RFC 6486、DOI 10.17487/RFC6486、2月2012年、<HTTPS：//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, DOI 10.17487/RFC6489, February 2012, <https://www.rfc-editor.org/info/rfc6489>.
[RFC6489] Huston、G.、Michaelson、G。、およびS. Kent、「認定局（CA）リソース公開キーインフラストラクチャ（RPKI）のキーロールオーバー」、BCP 174、RFC 6489、DOI 10.17487/RFC6489、2012年2月、<https://www.rfc-editor.org/info/rfc6489>。
RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0) 60 }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
- すべてエクスポート -
IMPORTS
輸入
CONTENT-TYPE
FROM CryptographicMessageSyntax-2010 -- in RFC 6268
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
-- Manifest Content Type
- マニフェストコンテンツタイプ
ct-rpkiManifest CONTENT-TYPE ::=
{ TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
END
終わり
In 2019, it came to light that multiple RP implementations were in a vulnerable position, possibly due to perceived ambiguity in the original [RFC6486] specification. This document attempts to clarify the innovative concept and application of RPKI manifests in light of real-world deployment experience in the global Internet routing system, to avoid future problematic cases.
2019年には、おそらく元の[RFC6486]仕様の曖昧さが認識されているため、複数のRP実装が脆弱な位置にあることが明らかになりました。このドキュメントは、将来の問題のあるケースを避けるために、グローバルなインターネットルーティングシステムでの実際の展開経験に照らして、RPKIマニフェストの革新的な概念と適用を明確にしようとします。
The following list summarizes the changes between RFC 6486 and this document:
次のリストは、RFC 6486とこのドキュメントの間の変更をまとめたものです。
* Forbidding "sequential-use" EE certificates and instead mandating "one-time-use" EE certificates.
* 「シーケンシャル」EE証明書を禁止し、代わりに「1回限りの」EE証明書を義務付けます。
* Clarifying that manifest EE certificates are to be issued with a validity period that coincides with the interval specified in the manifest eContent, which coincides with the CRL's thisUpdate and nextUpdate.
* Manifest EE証明書は、CRLのthisupdateとnextupdateと一致するマニフェストエコネントで指定された間隔と一致する有効期間で発行されることを明確にする。
* Clarifying that the manifestNumber is monotonically incremented in steps of 1.
* マニフェストナンバーが1のステップで単調に増加していることを明確にします。
* Recommending that CA issuers include the applicable CRL's nextUpdate with the manifest's nextUpdate.
* CA発行者には、ManifestのNextUpDateに該当するCRLのNextUpDateが含まれることを推奨します。
* Constraining the set of valid characters in FileAndHash file names.
* Fileandhashファイル名に有効な文字のセットを制約します。
* Clarifying that an RP unable to obtain the full set of files listed on a manifest is considered to be in a failure state, in which case cached data from a previous attempt should be used (if available).
* マニフェストにリストされているファイルの完全なセットを取得できないRPが障害状態にあると見なされることを明確にします。その場合、以前の試みからキャッシュされたデータを使用する必要があります（利用可能な場合）。
* Clarifying the requirement for a current CRL to be present, listed, and verified.
* 現在のCRLが存在し、リストされ、検証されるための要件を明確にする。
* Removing the notion of "local policy".
* 「ローカルポリシー」の概念を削除します。
Acknowledgements
謝辞
The authors would like to acknowledge the contributions from George Michaelson and Randy Bush in the preparation of the manifest specification. Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior. The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, Roman Danyliw, Lars Eggert, Robert Wilton, and Benjamin Kaduk for their helpful review of this document.
著者は、マニフェスト仕様の準備におけるジョージマイケルソンとランディブッシュからの貢献を認めたいと考えています。さらに、著者は、マニフェストの検証とRPの動作を明確にするための支援について、マークレイノルズとクリストファースモールに感謝したいと思います。著者はまた、Tim Bruijnzeels、Job Snijders、Oleg Muravskiy、Sean Turner、Adianto Wibisono、Murray Kucherawy、Francesca Palombini、Roman Danyliw、Lars Eggert、Robert Wilton、およびBenjamin Kadukのこの文書のレビューに感謝します。
Authors' Addresses
著者のアドレス
Rob Austein Arrcus, Inc. Email: sra@hactrn.net
Rob Austein Arrcus、Inc。電子メール：sra@hactrn.net
Geoff Huston APNIC 6 Cordelia St South Brisbane QLD 4101 Australia Email: gih@apnic.net
Geoff Huston Apnic 6 Cordelia St South Brisbane QLD 4101 Australiaメール：gih@apnic.net
Stephen Kent Independent Email: kent@alum.mit.edu
Stephen Kent Independent Email：kent@alum.mit.edu
Matt Lepinski New College Florida 5800 Bay Shore Rd. Sarasota, FL 34243 United States of America Email: mlepinski@ncf.edu
マット・レピンスキーニューカレッジフロリダ5800ベイショアロードフロリダ州サラソタ34243アメリカ合衆国電子メール：mlepinski@ncf.edu