[要約] RFC 6486は、RPKIのマニフェストに関する規格であり、RPKIのセキュリティと信頼性を向上させるための方法を提供します。このRFCの目的は、RPKIの運用者が正確なルート情報を提供し、インターネットのルーティングにおける偽装や攻撃を防止することです。
Internet Engineering Task Force (IETF) R. Austein
Request for Comments: 6486 ISC
Category: Standards Track G. Huston
ISSN: 2070-1721 APNIC
S. Kent
M. Lepinski
BBN
February 2012
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 "stale" (valid) data and deletion of signed objects.
このドキュメントは、リソース公開キーインフラストラクチャ（RPKI）で使用する「マニフェスト」を定義しています。マニフェストは、リポジトリでの公開を担当する当局に関連付けられたリポジトリ公開ポイント（ディレクトリ）のすべての署名されたオブジェクト（ファイル）のリストを含む署名されたオブジェクト（ファイル）です。各証明書、証明書取消リスト（CRL）、またはこのリポジトリの公開ポイントで公開されている当局によって発行されたその他のタイプの署名されたオブジェクトについて、マニフェストには、ファイルのコンテンツのハッシュを含むファイルの名前の両方が含まれています。マニフェストは、頼る当事者（RP）がリポジトリに対する特定の形式の攻撃を検出できるようにすることを目的としています。具体的には、RPがリポジトリの公開ポイントから取得された署名されたオブジェクトに対してマニフェストの内容をチェックすると、RPは「古い」（有効な）データと署名されたオブジェクトの削除を検出できます。
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/rfc6486.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6486で取得できます。
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. Manifest Scope ..................................................4
3. Manifest Signing ................................................4
4. Manifest Definition .............................................5
4.1. eContentType ...............................................5
4.2. eContent ...................................................5
4.2.1. Manifest ............................................5
4.3. Content-Type Attribute .....................................7
4.4. Manifest Validation ........................................7
5. Manifest Generation .............................................7
5.1. Manifest Generation Procedure ..............................7
5.2. Considerations for Manifest Generation .....................9
6. Relying Party Use of Manifests ..................................9
6.1. Tests for Determining Manifest State ......................10
6.2. Missing Manifests .........................................11
6.3. Invalid Manifests .........................................12
6.4. Stale Manifests ...........................................12
6.5. Mismatch between Manifest and Publication Point ...........13
6.6. Hash Values Not Matching Manifests ........................14
7. Publication Repositories .......................................15
8. Security Considerations ........................................15
9. IANA Considerations ............................................16
10. Acknowledgements ..............................................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................17
Appendix A. ASN.1 Module ..........................................18
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 provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not expired, but have since been superseded) or attacks that remove an object that should be present in the repository. To assist in the detection of such attacks, the RPKI repository system can 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 a man-in-the-middle attack on 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 Origination Authorizations (ROAs).
マニフェストはCRLでモデル化されています。これは、マニフェストリプレイなどを使用した古いマニフェストと潜在的な攻撃の検出に伴う問題は、CRLのものと同様です。RPKIリポジトリには、Route Origination Authorizations（ROA）などのデジタル署名されたオブジェクトでカバーされていないオブジェクトが含まれているため、マニフェストペイロードの構文はCRLとは異なります。
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]に記載されているように解釈される。
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.
* このCa。
Every RPKI signed object includes, in the Cryptographic Message Syntax (CMS) [RFC3370] 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）[RFC3370]オブジェクトのラッパー、それを検証するために使用されるEE証明書に含まれています[RFC6488]が含まれます。したがって、CAのリポジトリ公開ポイントでそのEE証明書を個別に公開する要件はありません。
Where multiple CA instances share a common publication point, as can occur when an entity 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インスタンスが共通の公開ポイントを共有する場合、エンティティがキーロールオーバー操作[RFC6489]を実行するときに発生する可能性のあるように、リポジトリの公開ポイントには複数のマニフェストが含まれます。この場合、各マニフェストは、関連するCAインスタンスの公開された製品のコレクションのみを記述します。
A CA's manifest is verified using an EE certificate. The SubjectInfoAccess (SIA) field of this EE certificate contains the access method OID of id-ad-signedObject.
CAのマニフェストは、EE証明書を使用して検証されます。このEE証明書のsubjectinfoaccess（SIA）フィールドには、id-ad-signedObjectのアクセスメソッドOIDが含まれています。
The CA MAY choose to sign only one manifest with each generated private key, and generate a new key pair for each new version of the manifest. This form of use of the associated EE certificate is termed a "one-time-use" EE certificate.
CAは、生成された各秘密鍵で1つのマニフェストのみに署名し、マニフェストの新しいバージョンごとに新しいキーペアを生成することを選択できます。関連するEE証明書のこの形式の使用は、「1回限りの」EE証明書と呼ばれます。
Alternatively, the CA MAY elect to use the same private key to sign a sequence of manifests. Because only a single manifest (issued under a single CA instance) is current at any point in time, the associated EE certificate is used to verify only a single object at a time. As long as the sequence of objects verified by this EE certificate are published using the same file name, then this sequential, multiple use of the EE certificate is also valid. This form of use of an EE certificate is termed a "sequential-use" EE certificate.
あるいは、CAは同じ秘密鍵を使用して、一連のマニフェストに署名することを選択する場合があります。単一のマニフェスト（単一のCAインスタンスの下で発行）のみが任意の時点で電流であるため、関連するEE証明書は、一度に単一のオブジェクトのみを検証するために使用されます。このEE証明書によって検証されたオブジェクトのシーケンスが同じファイル名を使用して公開されている限り、EE証明書のこのシーケンシャルな複数の使用も有効です。EE証明書のこの形式の使用は、「順次使用」EE証明書と呼ばれます。
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 value of 1.2.840.113549.1.9.16.1.26.
マニフェストのecontentTypeはID-CT-RPKIMANIFESTとして定義され、1.2.840.113549.1.9.16.1.26の数値を持っています。
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で指定される時間まで、またはマニフェストがより大きなマニフェスト数のいずれか最初の方で発行されるまで、名目上電流です。
If a "one-time-use" EE certificate is employed to verify a manifest, the EE certificate MUST have a validity period that coincides with
「1回限りの」EE証明書を使用してマニフェストを確認する場合、EE証明書には、
the interval from thisUpdate to nextUpdate, to prevent needless growth of the CA's CRL.
CAのCRLの不必要な成長を防ぐための、このupdateからnextupdateまでの間隔。
If a "sequential-use" EE certificate is employed to verify a manifest, the EE certificate's validity period needs to be no shorter than the nextUpdate time of the current manifest. The extended validity time raises the possibility of a substitution attack using a stale manifest, as described in Section 6.4.
「シーケンシャル使用」EE証明書がマニフェストを検証するために使用されている場合、EE証明書の有効期間は、現在のマニフェストのNextUpDate時間より短くする必要がありません。拡張された有効性時間は、セクション6.4で説明されているように、古いマニフェストを使用して置換攻撃の可能性を高めます。
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 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：このフィールドは、特定の出版ポイントに対して新しいマニフェストが発行されるたびに増加する整数です。このフィールドにより、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 handle number values up to 20 octets. Conforming manifest issuers MUST NOT use number values longer than 20 octets.
マニフェストはCRL仕様をモデル化するため、マニフェストナンバーはCRLNumberに類似しており、CRLNumber値の[RFC5280]のガイダンスは、マニフェストナンバーに使用できる数値の範囲に適しています。マニフェスト数には長い整数が含まれることが期待できます。マニフェスト検証剤は、最大20オクテットまでの数値を処理できる必要があります。適合マニフェスト発行者は、20オクテットより長い数値を使用してはなりません。
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.
thisupdate：このフィールドには、マニフェストが作成された時間が含まれています。このフィールドには、同じ名前のCRLフィールドに対して[RFC5280]で指定されているのと同じ形式の制約があります。
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 before the nextUpdate time. If a manifest encompasses a CRL, the nextUpdate field of the manifest MUST match that of the CRL's nextUpdate field, as the manifest will be re-issued when a new CRL is published. If a "one-time-use" EE certificate is used to verify the manifest, then when a new manifest is issued before the time specified in nextUpdate of the
当局がリポジトリの公開ポイントで公開した項目のいずれかを変更する場合、当局は次の時間前に新しいマニフェストを発行する必要があります。マニフェストがCRLを包含する場合、マニフェストの次のフィールドは、新しいCRLが公開されるとマニフェストが再発行されるため、CRLのnextupdateフィールドの次のフィールドと一致する必要があります。「1回限りの」EE証明書を使用してマニフェストを検証する場合、次の時間で指定された時間の前に新しいマニフェストが発行された場合
current manifest, the CA MUST also issue a new CRL that includes the EE certificate corresponding to the old manifest.
現在のマニフェストでは、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 [RFC6485].
FileHashalg：このフィールドには、当局がリポジトリに配置したファイルをハッシュするために使用されるハッシュアルゴリズムのOIDが含まれています。使用されるハッシュアルゴリズムは、RPKIアルゴリズムとキーサイズプロファイル仕様[RFC6485]に準拠する必要があります。
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は、問題のオブジェクトとファイルの内容のハッシュを含むリポジトリ公開ポイント（ディレクトリ）のファイルの名前で構成される順序付けられたペアです。
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に先行します。
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. If no key pair exists, or if using a "one-time-use" EE certificate with a new key pair, generate a key pair.
1. キーペアが存在しない場合、または新しいキーペアで「1回限りの使用」EE証明書を使用する場合、キーペアを生成します。
2. If using a "one-time-use" EE certificate, or if a key pair was generated in step 1, or if using a "sequential-use" EE certificate that will expire before the intended nextUpdate time of this manifest, issue an EE certificate for this key pair.
2. 「1回限りの使用」EE証明書を使用する場合、またはステップ1でキーペアが生成された場合、またはこのマニフェストの目的の次の時間の前に期限切れになる「シーケンシャル使用」EE証明書を使用する場合、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.
このEE証明書には、ID-AD-SignedObjectのアクセスMethod OID値を備えたSIA拡張機能アクセス説明フィールドが必要です。関連するアクセスロケーションは、マニフェストの公開ポイントをオブジェクトURLとして参照しています。
This EE certificate MUST describe its Internet Number Resources (INRs) using the "inherit" attribute, rather than explicit description of a resource set (see [RFC3779]).
このEE証明書は、リソースセットの明示的な説明ではなく、「継承」属性を使用して、インターネット番号リソース（INR）を記述する必要があります（[RFC3779]を参照）。
In the case of a "one-time-use" EE certificate, the validity times of the EE certificate MUST exactly match the thisUpdate and nextUpdate times of the manifest.
「1回限りの使用」EE証明書の場合、EE証明書の有効期間は、マニフェストのThisUpDateとNextDate時間と正確に一致する必要があります。
In the case of a "sequential-use" EE certificate, the validity times of the EE certificate MUST encompass the time interval from thisUpdate to nextUpdate.
「シーケンシャル使用」EE証明書の場合、EE証明書の有効期間は、このupdateからnextupdateまでの時間間隔を網羅する必要があります。
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.
マニフェストコンテンツは、セクション4.2.1で説明されています。マニフェストのファイルリストには、このリポジトリの出版ポイント（ディレクトリ）で公開されているこのCAによって発行された各オブジェクトのファイル名とハッシュペアが含まれています。マニフェストに含まれるオブジェクトのコレクションには、CAのリポジトリ公開ポイントで公開されているこのCAが発行したすべての証明書、CAが発行した最新のCRL、およびこのCAによって発行されたEE証明書によって検証されたすべてのオブジェクトが含まれます。このリポジトリの公開ポイントで公開されています。
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 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.
5. CMS SignedDataコンテンツタイプ（指定されたセクション4として）を使用してマニフェストコンテンツをカプセル化し、EE証明書に含まれる主題キーに対応する秘密鍵を使用してマニフェストに署名し、記述されているリポジトリシステムの公開ポイントにマニフェストを公開します。マニフェスト。
6. In the case of a key pair that is to be used only once, in conjunction with a "one-time-use" EE certificate, the private key associated with this key pair MUST now be destroyed.
6. 「1回限りの使用」EE証明書に関連して、1回だけ使用されるキーペアの場合、このキーペアに関連付けられた秘密鍵を破壊する必要があります。
A new manifest MUST be issued and published on or 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. 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 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.
当局は、出版ポイントのオブジェクトに加えられた変更の最終化と併せて新しいマニフェストを発行する必要があります。当局は、この変更の範囲内ですべての操作をカバーする単一のマニフェストを発行する前に、リポジトリ変更の範囲内で公開リポジトリ上で多くのオブジェクト操作を実行する場合があります。リポジトリオペレーターは、可能な限り、リポジトリで検索操作を実行している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つのマニフェストがあります。
The goal of an RP is to determine which signed objects to use for validating assertions about INRs and their use (e.g., which ROAs to use in the construction of route filters). Ultimately, this selection is a matter of local policy. However, in the following sections, we describe a sequence of tests that the RP SHOULD perform to determine the manifest state of the given publication point. We then discuss the risks associated with using signed objects in the publication point, given the manifest state; we also provide suitable warning text that SHOULD be placed in a user-accessible log file. It is the responsibility of the RP to weigh these risks against the risk of routing failure that could occur if valid data is rejected, and to implement a suitable local policy. Note that if a certificate is deemed unfit for use due to local policy, then any signed object that
RPの目標は、INRとその使用に関するアサーションを検証するために使用する署名されたオブジェクト（たとえば、ルートフィルターの構築で使用すること）を決定することです。最終的に、この選択はローカルポリシーの問題です。ただし、次のセクションでは、特定の公開ポイントのマニフェスト状態を決定するためにRPが実行する必要がある一連のテストについて説明します。次に、マニフェスト状態を考慮して、出版ポイントで署名されたオブジェクトを使用することに関連するリスクについて説明します。また、ユーザーアクセス可能なログファイルに配置する必要がある適切な警告テキストも提供します。有効なデータが拒否された場合に発生する可能性のあるルーティング障害のリスクに対してこれらのリスクを比較検討し、適切なローカルポリシーを実装することは、RPの責任です。証明書がローカルポリシーのために使用に適さないとみなされる場合、署名されたオブジェクトが
is validated using this certificate also SHOULD be deemed unfit for use (regardless of the status of the manifest at its own publication point).
この証明書を使用して検証されていることも、使用するのに適さないとみなされる必要があります（独自の出版ポイントでのマニフェストのステータスに関係なく）。
For a given publication point, the RP SHOULD perform the following tests to determine the manifest state of the publication point:
特定の出版点については、RPは次のテストを実行して、出版ポイントのマニフェスト状態を決定する必要があります。
1. For each CA using this publication point, select the CA's current manifest (the "current" manifest is the manifest issued by this CA having the highest manifestNumber among all valid manifests, and where manifest validity is defined in Section 4.4).
1. この公開ポイントを使用してCAの各CAについて、CAの現在のマニフェストを選択します（「現在の」マニフェストは、すべての有効なマニフェストの中で最も高いマニフェスト数を持つこのCAによって発行されたマニフェストであり、マニフェストの妥当性がセクション4.4で定義されています）。
If the publication point does not contain a valid manifest, see Section 6.2. Lacking a valid manifest, the following tests cannot be performed.
公開ポイントに有効なマニフェストが含まれていない場合は、セクション6.2を参照してください。有効なマニフェストがないため、以下のテストは実行できません。
2. To verify completeness, an RP MAY check that every file at each publication point appears in one and only one current manifest, and that every file listed in a current manifest is published at the same publication point as the manifest.
2. 完全性を確認するために、RPは、各公開ポイントのすべてのファイルが1つの電流マニフェストのみに表示され、現在のマニフェストにリストされているすべてのファイルがマニフェストと同じ出版ポイントで公開されることを確認できます。
If there exist files at the publication point that do not appear on any manifest, or files listed in a manifest that do not appear at the publication point, then see Section 6.5, but still continue with the following test.
マニフェストに表示されないファイル、または公開ポイントに表示されないマニフェストにリストされているファイルが存在する場合は、セクション6.5を参照してください。
3. Check that the current time (translated to UTC) is between thisUpdate and nextUpdate.
3. 現在の時刻（UTCに翻訳）がthisupdateとnextupdateの間にあることを確認してください。
If the current time does not lie within this interval, then see Section 6.4, but still continue with the following tests.
現在の時間がこの間隔内にある場合は、セクション6.4を参照してください。
4. Verify that the listed hash value of every file listed in each manifest matches the value obtained by hashing the file at the publication point.
4. 各マニフェストにリストされているすべてのファイルのリストされたハッシュ値が、公開ポイントでファイルをハッシュすることによって得られた値と一致することを確認します。
If the computed hash value of a file listed on the manifest does not match the hash value contained in the manifest, then see Section 6.6.
マニフェストにリストされているファイルの計算されたハッシュ値が、マニフェストに含まれるハッシュ値と一致しない場合は、セクション6.6を参照してください。
5. An RP MAY check that the contents of each current manifest conforms to the manifest's scope constraints, as specified in Section 2.
5. RPは、セクション2で指定されているように、各電流マニフェストの内容がマニフェストのスコープ制約に適合していることを確認する場合があります。
6. If a current manifest contains entries for objects that are not within the scope of the manifest, then the out-of-scope entries
6. 現在のマニフェストに、マニフェストの範囲内にないオブジェクトのエントリが含まれている場合、スコープ外のエントリは
SHOULD be disregarded in the context of this manifest. If there is no other current manifest that describes these objects within that other manifest's scope, then see Section 6.2.
このマニフェストの文脈で無視する必要があります。他のマニフェストの範囲内でこれらのオブジェクトを説明する他の電流マニフェストがない場合は、セクション6.2を参照してください。
For each signed object, if all of the following conditions hold:
署名されたオブジェクトごとに、次の条件がすべて続く場合は次のとおりです。
* the manifest for its publication and the associated publication point pass all of the above checks;
* その出版物と関連する出版ポイントのマニフェストは、上記のすべてのチェックを渡します。
* the signed object is valid; and
* 署名されたオブジェクトは有効です。と
* the manifests for every certificate on the certification path used to validate the signed object and the associated publication points pass all of the above checks;
* 署名されたオブジェクトを検証するために使用される認証パス上のすべての証明書のマニフェストと、関連する公開ポイントは上記のすべてのチェックをすべて通過します。
then the RP can conclude that no attack against the repository system has compromised the given signed object, and the signed object MUST be treated as valid (relative to manifest checking).
その後、RPは、リポジトリシステムに対する攻撃が与えられた署名されたオブジェクトを損なうことはないと結論付けることができ、署名されたオブジェクトは（マニフェストチェックと比較して）有効として扱わなければなりません。
The absence of a current manifest at a publication point could occur due to an error by the publisher or due to (malicious or accidental) deletion or corruption of all valid manifests.
出版社によるエラーのために、またはすべての有効なマニフェストの（悪意または偶発的な）削除または腐敗のために、出版ポイントで現在のマニフェストがない可能性があります。
When no valid manifest is available, there is no protection against attacks that delete signed objects or replay old versions of signed objects. All signed objects at the publication point, and all descendant objects that are validated using a certificate at this publication point, SHOULD be viewed as suspect, but MAY be used by the RP, as per local policy.
有効なマニフェストが利用できない場合、署名されたオブジェクトを削除したり、署名されたオブジェクトの古いバージョンを再生したりする攻撃に対する保護はありません。公開ポイントですべての署名されたオブジェクト、およびこの公開ポイントで証明書を使用して検証されたすべての子孫オブジェクトは、容疑者と見なされる必要がありますが、ローカルポリシーに従ってRPで使用される場合があります。
The primary risk in using signed objects at this publication point is that a superseded (but not stale) CRL would cause an RP to improperly accept a revoked certificate as valid (and thus rely upon signed objects that are validated using that certificate). This risk is somewhat mitigated if the CRL for this publication point has a short time between thisUpdate and nextUpdate (and the current time is within this interval). The risk in discarding signed objects at this publication point is that an RP may incorrectly discard a large number of valid objects. This gives significant power to an adversary that is able to delete a manifest at the publication point.
この公開ポイントで署名されたオブジェクトを使用することの主なリスクは、置き換えられた（古くしない）CRLにより、RPが失効した証明書を有効として不適切に受け入れることです（したがって、その証明書を使用して検証された署名されたオブジェクトに依存することです）。この出版ポイントのCRLがThisupdateとnextupdateの間で短い時間を持っている場合（そして、現在の時間はこの間隔内にある場合）、このリスクがいくらか軽減されます。この公開ポイントで署名されたオブジェクトを破棄するリスクは、RPが多数の有効なオブジェクトを誤って破棄する可能性があることです。これにより、出版ポイントでマニフェストを削除できる敵に大きな力が与えられます。
Regardless of whether signed objects from this publication are deemed fit for use by an RP, this situation SHOULD result in a warning to the effect that: "No manifest is available for <pub point name>, and thus there may have been undetected deletions or replay substitutions from the publication point."
この出版物の署名されたオブジェクトがRPが使用するのに適しているとみなされるかどうかに関係なく、この状況は次のような効果に警告するはずです。出版ポイントから代替を再生します。」
In the case where an RP has access to a local cache of previously issued manifests that are valid, the RP MAY use the most recently previously issued valid manifests for this RPKI repository publication collection for each entity that publishes at this publication point.
RPが有効な以前に発行されたマニフェストのローカルキャッシュにアクセスできる場合、RPは、この出版ポイントで公開されている各エンティティのこのRPKIリポジトリ出版物コレクションに対して以前に発行された最近発行された有効なマニフェストを使用する場合があります。
The presence of an invalid manifest at a publication point could occur due to an error by the publisher or due to (malicious or accidental) corruption of a valid manifest. An invalid manifest MUST never be used, even if the manifestNumber of the invalid manifest is greater than that of other (valid) manifests.
出版ポイントでの無効なマニフェストの存在は、出版社によるエラーのために発生する可能性があります。無効なマニフェストのマニフェスト数が他の（有効な）マニフェストのマニフェストよりも大きい場合でも、無効なマニフェストを使用してはなりません。
There are no risks associated with using signed objects at a publication point containing an invalid manifest, provided that valid manifests that collectively cover all the signed objects are also present.
無効なマニフェストを含む公開ポイントで署名されたオブジェクトを使用することに関連するリスクはありません。
If an invalid manifest is present at a publication point that also contains one or more valid manifests, this situation SHOULD result in a warning to the effect that: "An invalid manifest was found at <pub point name>, this indicates an attack against the publication point or an error by the publisher. Processing for this publication point will continue using the most recent valid manifest(s)."
無効なマニフェストが1つ以上の有効なマニフェストを含む出版ポイントに存在する場合、この状況は次のような効果に対する警告をもたらすはずです。出版社による出版ポイントまたはエラー。この出版ポイントの処理は、最新の有効なマニフェストを使用し続けます。」
In the case where the RP has access to a local cache of previously issued (valid) manifests, an RP MAY make use of that locally cached data. Specifically, the RP MAY use the locally cached, most recent, previously issued, valid manifest issued by the entity that (appears to have) issued the invalid manifest.
RPが以前に発行された（有効な）マニフェストのローカルキャッシュにアクセスできる場合、RPはそのローカルでキャッシュされたデータを利用する場合があります。具体的には、RPは、地元でキャッシュされた最新の、以前に発行された、（持っているように見える）エンティティが発行した有効なマニフェストを無効なマニフェストを使用する場合があります。
A manifest is considered stale if the current time is after the nextUpdate time for the manifest. This could be due to publisher failure to promptly publish a new manifest, or due to (malicious or accidental) corruption or suppression of a more recent manifest.
マニフェストは、マニフェストのnextupdate時間の後にある場合、古くなっていると見なされます。これは、出版社が新しいマニフェストを迅速に公開できなかったこと、またはより最近のマニフェストの（悪意のある）腐敗または抑制によるものです。
All signed objects at the publication point issued by the entity that has published the stale manifest, and all descendant signed objects that are validated using a certificate issued by the entity that has published the stale manifest at this publication point, SHOULD be viewed as somewhat suspect, but MAY be used by the RP as per local policy.
古いマニフェストを公開したエンティティによって発行された公開ポイントにあるすべての署名されたオブジェクト、およびこの出版ポイントで古いマニフェストを発行したエンティティによって発行された証明書を使用して検証されたすべての子孫の署名されたオブジェクトは、やや疑わしいと見なされるべきです、しかし、ローカルポリシーに従ってRPで使用される場合があります。
The primary risk in using such signed objects is that a newer manifest exists that, if present, would indicate that certain objects
そのような署名されたオブジェクトを使用する際の主なリスクは、存在する場合、特定のオブジェクトを示す新しいマニフェストが存在することです
have been removed or replaced. (For example, the new manifest might show the existence of a newer CRL and the removal of one or more revoked certificates). Thus, the use of objects from a stale manifest may cause an RP to incorrectly treat invalid objects as valid. The risk is that the CRL covered by the stale manifest has been superseded, and thus an RP will improperly treat a revoked certificate as valid. This risk is somewhat mitigated if the time between the nextUpdate field of the manifest and the current time is short. The risk in discarding signed objects at this publication point is that the RP may incorrectly discard a large number of valid objects. This gives significant power to an adversary that is able to prevent the publication of a new manifest at a given publication point.
削除または交換されました。（たとえば、新しいマニフェストは、新しいCRLの存在と1つ以上の取り消された証明書の削除を示す場合があります）。したがって、古いマニフェストからオブジェクトを使用すると、RPが無効なオブジェクトを有効であると誤って扱うことがあります。リスクは、古いマニフェストの対象となるCRLが置き換えられているため、RPが取り消された証明書を有効であると不適切に扱うことです。このリスクは、マニフェストのnextupdateフィールドと現在の時間が短い場合、やや軽減されます。この公開ポイントで署名されたオブジェクトを破棄するリスクは、RPが多数の有効なオブジェクトを誤って破棄する可能性があることです。これは、特定の出版ポイントで新しいマニフェストの出版を防ぐことができる敵に大きな力を与えます。
Regardless of whether signed objects from this publication are deemed fit for use by an RP, this situation SHOULD result in a warning to the effect that: "A manifest found at <pub point name> is no longer current. It is possible that undetected deletions have occurred at this publication point."
この出版物の署名されたオブジェクトがRPが使用するのに適しているとみなされるかどうかに関係なく、この状況は次のような結果に警告を発するはずです。この出版物で発生しました。」
Note that there is also the potential for the current time to be before the thisUpdate time for the manifest. This case could be due to publisher error or a local clock error; in such a case, this situation SHOULD result in a warning to the effect that: "A manifest found at <pub point name> has an incorrect thisUpdate field. This could be due to publisher error, or a local clock error, and processing for this publication point will continue using this otherwise valid manifest."
マニフェストのためのこの最中に時間の前にある可能性もあることに注意してください。このケースは、出版社のエラーまたはローカルクロックエラーが原因である可能性があります。そのような場合、この状況は次のような効果に対する警告をもたらすはずです。この出版ポイントは、そうでなければ有効なマニフェストを使用し続けます。」
If there exist valid signed objects that do not appear in any manifest, then, provided the manifest is not stale (see Section 6.4), it is likely that their omission is an error by the publisher. It is also possible that this state could be the result of a (malicious or accidental) replacement of a current manifest with an older, but still valid, manifest. However, regarding the appropriate interpretation of such objects, it remains the case that if the objects were intended to be invalid, then they should have been revoked using whatever revocation mechanism is appropriate for the signed object in question. Therefore, there is little risk in using such signed objects. If the publication point contains a stale manifest, then there is a greater risk that the objects in question were revoked, along with a missing Certificate Revocation List (CRL), the absence of which is undetectable since the manifest is stale. In any case, the use of signed objects not present on a manifest, or descendant objects that are validated using such signed objects, is a matter of local policy.
マニフェストに表示されない有効な署名されたオブジェクトが存在する場合、マニフェストが古くない場合（セクション6.4を参照）、それらの省略は出版社によるエラーである可能性があります。また、この状態が、電流マニフェストを古い、しかしまだ有効なマニフェストに置き換える（悪意のある、または偶発的な）置き換えの結果である可能性もあります。ただし、そのようなオブジェクトの適切な解釈に関しては、オブジェクトが無効であることを意図していた場合、問題の署名されたオブジェクトに適している取り消しメカニズムを使用して取り消されるべきであるということです。したがって、そのような署名されたオブジェクトを使用するリスクはほとんどありません。出版ポイントに古いマニフェストが含まれている場合、問題のオブジェクトが取り消されたという大きなリスクがあり、証明書の失効リスト（CRL）が欠落しています。いずれにせよ、そのような署名されたオブジェクトを使用して検証されたマニフェストまたは子孫オブジェクトに存在しない署名されたオブジェクトの使用は、ローカルポリシーの問題です。
Regardless of whether objects not appearing on a manifest are deemed
fit for use by the RP, this situation SHOULD result in a warning to
the effect that: "The following files are present in the repository
at <pub point name>, but are not listed on any manifest <file list>
for <pub point name>."
If there exists files listed on the manifest that do not appear in the repository, then these objects are likely to have been improperly (via malice or accident) deleted from the repository. A primary purpose of manifests is to detect such deletions. Therefore, in such a case, this situation SHOULD result in a warning to the effect that: "The following files that should have been present in the repository at <pub point name> are missing <file list>. This indicates an attack against this publication point, or the repository, or an error by the publisher."
リポジトリに表示されないマニフェストにリストされているファイルが存在する場合、これらのオブジェクトはリポジトリから削除された（悪意または事故を介して）不適切に（悪意または事故を介して）削除された可能性があります。マニフェストの主な目的は、そのような削除を検出することです。したがって、そのような場合、この状況は次のような効果に対する警告をもたらすはずです。出版ポイント、またはリポジトリ、または出版社によるエラー。」
A file appearing on a manifest with an incorrect hash value could occur because of publisher error, but it also may indicate that an attack has occurred.
誤ったハッシュ値を持つマニフェストに表示されるファイルは、パブリッシャーのエラーのために発生する可能性がありますが、攻撃が発生したことも示している可能性があります。
If an object appeared on a previous valid manifest with a correct hash value, and it now appears with an invalid hash value, then it is likely that the object has been superseded by a new (unavailable) version of the object. If the object is used, there is a risk that the RP will be treating a stale object as valid. This risk is more significant if the object in question is a CRL. If the object can be validated using the RPKI, the use of these objects is a matter of local policy.
オブジェクトが正しいハッシュ値を持つ以前の有効なマニフェストに表示され、無効なハッシュ値で表示されると、オブジェクトがオブジェクトの新しい（利用できない）バージョンに取って代わられた可能性があります。オブジェクトを使用すると、RPが古いオブジェクトを有効として扱うリスクがあります。問題のオブジェクトがCRLである場合、このリスクはより重要です。RPKIを使用してオブジェクトを検証できる場合、これらのオブジェクトの使用はローカルポリシーの問題です。
If an object appears on a manifest with an invalid hash and has never previously appeared on a manifest, then it is unclear whether the available version of the object is more or less recent than the version indicated by the manifest. If the manifest is stale (see Section 6.4), then it becomes more likely that the available version is more recent than the version indicated on the manifest, but this is never certain. Whether to use such objects is a matter of local policy. However, in general, it is better to use a possibly outdated version of the object than to discard the object completely.
オブジェクトが無効なハッシュを持つマニフェストに表示され、以前にマニフェストに表示されたことがない場合、オブジェクトの使用可能なバージョンがマニフェストで示されているバージョンよりも多かれ少なかれ最近であるかどうかは不明です。マニフェストが古くなっている場合（セクション6.4を参照）、利用可能なバージョンはマニフェストに示されているバージョンよりも最近である可能性が高くなりますが、これは決して確実ではありません。そのようなオブジェクトを使用するかどうかは、ローカルポリシーの問題です。ただし、一般に、オブジェクトを完全に破棄するよりも、オブジェクトの可能性のあるバージョンを使用する方が良いです。
While it is a matter of local policy, in the case of CRLs, an RP SHOULD endeavor to use the most recently issued valid CRL, even where the hash value in the manifest matches an older CRL or does not match any available CRL for a CA instance. The thisUpdate field of the CRL can be used to establish the most recent CRL in the case where an RP has more than one valid CRL for a CA instance.
それはローカルポリシーの問題ですが、CRLSの場合、RPは、マニフェストのハッシュ値が古いCRLと一致するか、CAで利用可能なCRLと一致しない場合でも、最近発行された有効なCRLを使用するように努力する必要があります実例。CRLのThisupDateフィールドを使用して、RPがCAインスタンスに対して複数の有効なCRLを持っている場合に最新のCRLを確立できます。
Regardless of whether objects with incorrect hashes are deemed fit for use by the RP, this situation SHOULD result in a warning to the effect that: "The following files at the repository <pub point name> appear on a manifest with incorrect hash values <file list>. It is possible that these objects have been superseded by a more recent version. It is very likely that this problem is due to an attack on the publication point, although it also could be due to a publisher error."
誤ったハッシュを持つオブジェクトがRPが使用するのに適しているとみなされるかどうかに関係なく、この状況は次の効果に警告するはずです。リスト>。これらのオブジェクトは、より最近のバージョンに取って代わられた可能性があります。この問題は、出版ポイントへの攻撃によるものである可能性が非常に高いですが、出版社のエラーが原因である可能性があります。」
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, namely, the CRL issued by the CA upon repository creation [RFC6481].
RPKI出版システムモデルでは、すべての出版ポイントが1つ以上のCAに関連付けられ、空でないことが必要です。CAに関連付けられた出版ポイントが作成されると、CAはCRLと同様にマニフェストを作成および公開する必要があります。CAのマニフェストには、常に少なくとも1つのエントリ、つまりリポジトリ作成時にCAが発行したCRL [RFC6481]が含まれます。
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 to determine 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 allows 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 attack
マニフェストの署名構造とNextUpDate値の使用により、RPはマニフェスト自体が変更された変更の対象であるかどうかを判断できます。すべてのリポジトリの出版物が少なくとも1つのマニフェストを含むことをポイントすることにより、RPはマニフェスト自体がビューから閉塞されているかどうかを判断できます。マニフェストに対するこのような攻撃は、マニフェストの更新の通常のスケジュールの時間枠内で検出可能です。リプレイ攻撃の形式
within finer-grained time frames are not necessarily detectable by the manifest structure.
細かい粒度の時間内で、マニフェスト構造によって必ずしも検出可能ではありません。
This document registers the following in the "RPKI Signed Object" registry created by [RFC6488]:
このドキュメントは、[RFC6488]によって作成された「RPKI署名されたオブジェクト」レジストリで以下を登録します。
Name: Manifest OID: 1.2.840.113549.1.9.16.1.26 Reference: [RFC6486] (this document)
名前：マニフェストOID：1.2.840.113549.1.9.16.1.26リファレンス：[RFC6486]（このドキュメント）
This document registers the following three-letter filename extension for "RPKI Repository Name Schemes" registry created by [RFC6481]:
このドキュメントは、[RFC6481]によって作成された「RPKIリポジトリ名スキーム」レジストリの次の3文字のファイル名拡張機能を登録します。
Filename extension: mft RPKI Object: Manifest Reference: [RFC6481]
ファイル名拡張：MFT RPKIオブジェクト：マニフェストリファレンス：[RFC6481]
The authors would like to acknowledge the contributions from George Michelson 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 Sean Turner for his helpful review of this document.
著者は、マニフェスト仕様の準備におけるジョージ・マイケルソンとランディ・ブッシュからの貢献を認めたいと考えています。さらに、著者は、マニフェストの検証とRPの動作を明確にするための支援について、マークレイノルズとクリストファースモールに感謝したいと思います。著者はまた、この文書の有益なレビューについてショーン・ターナーに感謝したいと考えています。
[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月。
[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月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、2012年2月。
[RFC6485] Huston, G., "A Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.
[RFC6485] Huston、G。、「リソース公開キーインフラストラクチャ（RPKI）で使用するアルゴリズムとキーサイズのプロファイル」、RFC 6485、2012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、2012年2月。
[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月。
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X.690] ITU-T推奨X.690（2002）|ISO/IEC 8825-1：2002、情報技術-ASN.1エンコーディングルール：基本エンコードルール（BER）、標準エンコーディングルール（CER）、および識別されたエンコードルール（DER）の仕様。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370] Housley、R。、「暗号化メッセージ構文（CMS）アルゴリズム」、RFC 3370、2002年8月。
[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月。
[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月。
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 NOTHING --
- 何も輸入しません -
-- Manifest Content Type: OID
- マニフェストコンテンツタイプ：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 }
-- Manifest Content Type: eContent
- マニフェストコンテンツタイプ：econtent
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
終わり
Authors' Addresses
著者のアドレス
Rob Austein Internet Systems Consortium
Rob Austein Internet Systems Consortium
EMail: sra@hactrn.net
Geoff Huston APNIC 6 Cordelia St South Brisbane, QLD 4101 Australia
Geoff Huston Apnic 6 Cordelia St South Brisbane、QLD 4101 Australia
EMail: gih@apnic.net
URI: http://www.apnic.net
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Stephen Kent BBN Technologies 10 Moulton St. Cambridge、MA 02138 USA
EMail: kent@bbn.com
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge、MA 02138 USA
EMail: mlepinski@bbn.com