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)
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................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]の使用は、信頼者（RPS）が必要とするさまざまなオブジェクトを利用できるようになります。リポジトリシステムに保存されているオブジェクトのすべてがデジタルでそれらを作成したエンティティによって署名されているので、これらの公表されたオブジェクトを変更する攻撃はのRPによって検出可能です。しかしながら、デジタル署名が攻撃に対する保護を提供しないこと署名されたオブジェクトの代替「古い」バージョン（すなわち、有効であり、有効期限が切れていないが、以来、取って代わられているオブジェクト）またはリポジトリ中に存在すべきオブジェクトを削除攻撃。このような攻撃の検出を支援するために、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が不正なオブジェクトの除去または出版時点におけるオブジェクトの失効バージョンの置換を検出することを可能にすることを意図しています。マニフェストはまた、リポジトリからオブジェクトの検索にman-in-the-middle攻撃から生じる同様の結果を検出するためにRPを可能にするように意図されています。マニフェスト発行ポイントはリポジトリに認証局（CA）で使用されることを意図している（エンドエンティティ（EE）証明書によって検証され、このCAおよびその他の署名のオブジェクトによって発行された下位証明書と証明書失効リスト（CRL）のあるファイルを含むディレクトリこの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リポジトリは、CRLを、そのような経路発信権限として例えば、デジタル署名オブジェクト、（資産収益率）によって覆われていないオブジェクトを含むので、マニフェストペイロードの構文は、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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によって発行され、発行された証明書（非有効期限が切れ、失効していない）のセット
* the most recent CRL issued by this CA, and
*最新のCRLは、このCAによって発行され、
* all published signed objects that are verifiable using EE certificates [RFC6487] issued by this CA.
*検証EE証明書を使用しているすべての公開署名したオブジェクトは、[RFC6487]は、この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.
エンティティは、キーロールオーバ動作[RFC6489]を行った場合、リポジトリ出版ポイントは、複数のマニフェストを含むであろう起こり得る通りである複数のCAインスタンスが、共通の出版点を共有します。この場合、各マニフェストは、それに関連する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は、各生成した秘密鍵を使用して唯一のマニフェストに署名することを選択して、マニフェストのそれぞれの新しいバージョンのために新しい鍵ペアを生成してもよいです。関連するEE証明書の使用のこの形式は、「使い切り」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]を使用してエンコードASN.1です。次のようにマニフェストの内容が定義されています。
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フィールドは509のCRLの対応するフィールドの後にモデル化される（[RFC5280]を参照）。 CRLのと同様に、マニフェストは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 the interval from thisUpdate to nextUpdate, to prevent needless growth of the CA's CRL.
「使い切り」EE証明書がマニフェストを検証するために採用されている場合は、EE証明書は、CAのCRLの不要な増殖を防ぐために、thisUpdateのから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の仕様にモデル化されているように、ManifestNumberはCRLNumberに類似しており、そしてCRLNumber値の[RFC5280]のガイダンスはmanifestNumberために使用することができる数値の範囲として適当です。マニフェストの数字は長整数を含むことが期待できます。マニフェスト検証は、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のフィールドに必要とされるようGeneralizedTimeの値の仕様は同じです。
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 current manifest, the CA MUST also issue a new CRL that includes the EE certificate corresponding to the old manifest.
当局は、それがリポジトリ出版時点で公開された項目のいずれかを変更した場合、当局はnextUpdateの時間の前に新しいマニフェストを発行しなければなりません。マニフェストは、CRLを包含している場合、新しいCRLが公開されたときにマニフェストが再発行されるように、マニフェストのnextUpdateのフィールドは、CRLのnextUpdateのフィールドのものと一致しなければなりません。 「使い切り」EE証明書がマニフェストを検証するために使用されている場合は、新しいマニフェストは、現在のマニフェストの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 [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.
必須コンテンツ-type属性は、そのattrValuesフィールドはのeContentTypeと同じOIDに設定する必要があります。この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. EncapsulatedContentInfo内のeContentTypeは、ID-AD-rpkiManifest（OID 1.2.840.113549.1.9.16.1.26）です。
If the above procedure indicates that the manifest is invalid, then the manifest MUST be discarded and treated as though no manifest were present.
上記の手順は、マニフェストが無効であることを示す場合、マニフェストを捨てなければならないとNOマニフェストが存在しないかのように処理しました。
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.何のキーのペアが存在しない場合、または新しいキーペアで「使い切り」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.
「使い切り」EE証明書を使用して2.の場合、または鍵ペアが、ステップ1で生成された場合、またはこのマニフェストの意図nextUpdateの時間の前に失効する「シーケンシャル・利用」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.
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証明書ではなく、リソースのセット（[RFC3779]を参照）の明示的な記述よりも、属性を「継承」を使ってインターネット番号リソース（INRS）を記述しなければなりません。
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.
「使い切り」EE証明書の場合は、EE証明書の有効時間が正確にマニフェストのthisUpdateおよびnextUpdateの時間を一致させる必要があります。
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証明書の有効時間はthisUpdateのからnextUpdateのに時間間隔を網羅しなければなりません。
3. The EE certificate MUST NOT be published in the authority's repository publication point.
3. EE証明書は、機関リポジトリの出版時点で公開されてはなりません。
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によって発行されたEE証明書によって検証CAのリポジトリ公開ポイント、CAによって発行された最新のCRLに掲載されている。このCAによって発行されたすべての証明書、およびすべてのオブジェクトが含まれていますこのリポジトリ出版時点で公開されています。
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.（指定されたセクション4として）、EE証明書に含まれる被写体の鍵に対応する秘密鍵を使用して、マニフェストに署名し、そして記載されているリポジトリシステム公開点でマニフェストを公開するCMSのSignedDataコンテンツタイプを使用して、マニフェストコンテンツをカプセル化マニフェストによります。
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.
「一回使用」EE証明書と一緒に、一度だけ使用される鍵ペアの場合には6は、この鍵ペアに関連付けられた秘密鍵は、現在破壊されなければなりません。
A new manifest MUST be issued and published on or before the nextUpdate time.
新しいマニフェストはnextUpdateの時間にまたはの前に発行され、公表されなければなりません。
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.
当局は出版ポイントのオブジェクトに加えられた変更のファイナライズと一緒に新しいマニフェストを発行しなければなりません。当局は、この変化の範囲内でのすべての操作をカバーする単一のマニフェストを発行する前に、リポジトリ変化の範囲内で出版リポジトリにオブジェクトの操作の数を実行することができます。リポジトリオペレータは、リポジトリ出版ポイント（ディレクトリ）に可能な限り、緩和リポジトリ更新手順、リポジトリ上で検索操作を実行しているのRPを更新中矛盾、一過、中間状態にさらされているリスクのいくつかのフォームを実装する必要があり、および関連するマニフェスト。
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のインスタンスに関連する一つマニフェストが存在することになります。
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 is validated using this certificate also SHOULD be deemed unfit for use (regardless of the status of the manifest at its own publication point).
RPの目標は、INRSおよびそれらの使用（例えば、資産収益率は、ルートフィルタの構築に使用する）に関するアサーションを検証するために使用するオブジェクトに署名したかを決定することです。最終的に、この選択は、ローカルポリシーの問題です。ただし、以下のセクションでは、我々は、RPが所定出版点のマニフェスト状態を決定するために実行すべきテストのシーケンスを記述する。我々は、次に、マニフェスト状態所与、刊行点で署名されたオブジェクトを使用することに関連するリスクを議論します。我々はまた、ユーザがアクセス可能なログファイルに配置する必要があり、適切な警告テキストを提供しています。有効なデータが拒否された場合に発生する可能性があり、かつ、適切なローカルポリシーを実装するために失敗をルーティングするリスクに対して、これらのリスクを比較検討するためにRPの責任です。証明書が原因ローカルポリシーに使用するのに適さないと考えられる場合は、この証明書を用いて検証され、任意の署名されたオブジェクトが（関係なく、独自の出版点でマニフェストの状態の）使用に適さないとみなされるべきであることに注意してください。
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).
この公報ポイントを使用して、各CAの1、CAの現在のマニフェストを選択し（「現在の」マニフェストは、すべての有効なマニフェストの中で最も高いmanifestNumberを有するこの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は、各パブリケーション・ポイントですべてのファイルは、唯一の現在のマニフェストに表示され、現在のマニフェストに記載されているすべてのファイルは、マニフェストと同じ出版時点で公開されていることいることを確認できます。
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.
（UTCに変換）現在時刻がthisUpdateおよびnextUpdateの間にある3チェック。
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.
出版点で無効なマニフェストの存在は、有効なマニフェストの（悪意のあるまたは偶発）破損にパブリッシャまたは原因によりエラーにより発生する可能性があります。無効なマニフェストは、無効なマニフェストのmanifestNumberは、他の（有効な）マニフェストのそれよりも大きい場合であっても、使用してはなりません。
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."
マニフェストのためのthisUpdateの時間の前になるように、現在の時間のための可能性もあることに注意してください。この場合は、パブリッシャエラーまたはローカル・クロック・エラーが原因である可能性があります。このような場合に、この状況は、その旨の警告が発生する必要があります。「<パブポイント名>で見つけマニフェスト間違ったthisUpdateのフィールドを持っているこれは、出版社のエラー、またはローカルクロックエラー、および処理のために可能性がありこの刊行点は、このそうでない場合は、有効なマニフェストを使用していきます。」
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>."
かかわらず、マニフェストに表示されないオブジェクトは、RPが使用するための適合とみなされているかどうかの、この状況は旨の警告を生じるはずである：以下のファイルは、<パブポイント名>のリポジトリに存在している」が、記載されていません<パブポイント名>のための任意のマニフェスト<ファイルリスト>に。」
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.
それがローカルポリシーの問題ですが、CRLをする場合には、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のマニフェストは常にCRLは、リポジトリの作成[RFC6481]によりCAによって発行された、すなわち、少なくとも1つのエントリが含まれます。
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のRPのための追加の保護レベルを提供します。マニフェストは、リポジトリオブジェクトが、閉塞削除、または他のビューから削除、又はオブジェクトの新しいバージョンの公開が抑制されている場合（オブジェクトの古いバージョンが置換されている）されているかどうかを決定するために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 within finer-grained time frames are not necessarily detectable by the manifest structure.
マニフェストおよびnextUpdate値の使用の締結構造は、マニフェスト自体が試み変更の対象である場合RPが決定することを可能にします。少なくとも一つのマニフェストを含有するすべてのリポジトリ出版ポイントの要件は、マニフェスト自体が視界から閉塞されているかどうかを決定するためにRPを可能にします。マニフェストに対するこのような攻撃は、マニフェストのアップデートの定期的なスケジュールの時間枠内で検出可能です。より細かい時間枠内リプレイ攻撃の形は必ずしもマニフェスト構造によって検出されません。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]ヒューストン、G.、Loomans、R.、およびG.マイケルソン、 "リソース証明書リポジトリの構造用プロフィール"、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]ヒューストン、G.、「リソース公開鍵インフラストラクチャで使用するためのアルゴリズムと鍵のサイズのためのプロファイル（RPKI）」、RFC 6485、2012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487]ヒューストン、G.、マイケルソン、G.、およびR. Loomans、 "X.509 PKIXリソース証明書のプロファイル"、RFC 6487、2012年2月。
[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.、チー、A.、およびS.ケントは、RFC 6488、2012年2月 "リソースの公開鍵インフラストラクチャ（RPKI）のためのオブジェクト・テンプレートを署名"。
[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）の仕様、Canonicalの符号化規則（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]リン、C.、ケント、S.、およびK.ソ、 "IPアドレスとAS識別子のための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.ケント、 "安全なインターネットルーティングをサポートするインフラストラクチャ"、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]ヒューストン、G.、マイケルソン、G.、およびS.ケント、 "リソース公開鍵インフラストラクチャにおける認証局（CA）キーロールオーバー（RPKI）"、BCP 174、RFC 6489、2012年2月。
Appendix A. ASN.1 Module
付録A. ASN.1モジュール
RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) mod(0) 60 }
RPKIManifest {ISO（1）部材本体（2）米国（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
- マニフェストコンテンツタイプ：e-コンテンツ
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
ロブAusteinとインターネットシステムコンソーシアム
EMail: sra@hactrn.net
メールアドレス：sra@hactrn.net
Geoff Huston APNIC 6 Cordelia St South Brisbane, QLD 4101 Australia
ジェフ・ヒューストンAPNIC 6コーデリアセントサウスブリスベン、QLD 4101オーストラリア
EMail: gih@apnic.net URI: http://www.apnic.net
電子メール：gih@apnic.net URI：http://www.apnic.net
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
スティーブン・ケントBBNテクノロジーズ10モールトンセントケンブリッジ、MA 02138 USA
EMail: kent@bbn.com
メールアドレス：kent@bbn.com
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
マット・Lepinski BBNテクノロジーズ10モールトンセントケンブリッジ、MA 02138 USA
EMail: mlepinski@bbn.com
メールアドレス：mlepinski@bbn.com