RFC 8488 - RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8488
タイトル : RFC 8488 - RIPE NCCによるResource Public Key Infrastructure（RPKI）証明書ツリーの検証の実装
翻訳編集 : 自動生成

[要約] 要約：RFC 8488は、RIPE NCCがResource Public Key Infrastructure（RPKI）証明書ツリーの検証を実装するためのガイドラインです。目的：このRFCの目的は、RPKI証明書ツリーの検証に関するRIPE NCCの実装を提供し、インターネットのセキュリティと信頼性を向上させることです。

Internet Engineering Task Force (IETF)                      O. Muravskiy
Request for Comments: 8488                                      RIPE NCC
Category: Informational                                   T. Bruijnzeels
ISSN: 2070-1721                                               NLnet Labs
                                                           December 2018

RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation

RIPE NCCによるResource Public Key Infrastructure（RPKI）証明書ツリーの検証の実装

Abstract

概要

This document describes an approach to validating the content of the Resource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both.

このドキュメントでは、RIPE NCC RPKI Validatorに実装されている、リソース公開鍵インフラストラクチャ（RPKI）証明書ツリーの内容を検証する方法について説明します。このアプローチは、特定のオブジェクト取得メカニズムに依存しません。これにより、rsyncプロトコル、RPKIリポジトリデルタプロトコル（RRDP）、および両方を組み合わせて使用するリポジトリで使用可能なリポジトリを使用できます。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8488.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8488で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  General Considerations  . . . . . . . . . . . . . . . . . . .   4
     2.1.  Hash Comparisons  . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Discovery of RPKI Objects Issued by a CA  . . . . . . . .   5
     2.3.  Manifest Entries versus Repository Content  . . . . . . .   5
   3.  Top-Down Validation of a Single Trust Anchor Certificate Tree   6
     3.1.  Fetching the Trust Anchor Certificate Using the Trust
           Anchor Locator  . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  CA Certificate Validation . . . . . . . . . . . . . . . .   7
       3.2.1.  Finding the Most Recent Valid Manifest and CRL  . . .   8
       3.2.2.  Validating Manifest Entries . . . . . . . . . . . . .   9
     3.3.  Object Store Cleanup  . . . . . . . . . . . . . . . . . .  10
   4.  Remote Objects Fetcher  . . . . . . . . . . . . . . . . . . .  11
     4.1.  Fetcher Operations  . . . . . . . . . . . . . . . . . . .  11
       4.1.1.  Fetch Repository Objects  . . . . . . . . . . . . . .  12
       4.1.2.  Fetch Single Repository Object  . . . . . . . . . . .  12
   5.  Local Object Store  . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Store Operations  . . . . . . . . . . . . . . . . . . . .  12
       5.1.1.  Store Repository Object . . . . . . . . . . . . . . .  12
       5.1.2.  Get Objects by Hash . . . . . . . . . . . . . . . . .  12
       5.1.3.  Get Certificate Objects by URI  . . . . . . . . . . .  13
       5.1.4.  Get Manifest Objects by AKI . . . . . . . . . . . . .  13
       5.1.5.  Delete Objects for a URI  . . . . . . . . . . . . . .  13
       5.1.6.  Delete Outdated Objects . . . . . . . . . . . . . . .  13
       5.1.7.  Update Object's Validation Time . . . . . . . . . . .  13
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     7.1.  Hash Collisions . . . . . . . . . . . . . . . . . . . . .  13
     7.2.  Algorithm Agility . . . . . . . . . . . . . . . . . . . .  13
     7.3.  Mismatch between the Expected and Actual Location of an
           Object in the Repository  . . . . . . . . . . . . . . . .  14
     7.4.  Manifest Content versus Publication Point Content . . . .  14
     7.5.  Possible Denial of Service  . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction

1. はじめに

This document describes how the RIPE NCC RPKI Validator version 2.25 has been implemented. Source code for this software can be found at [rpki-validator]. The purpose of this document is to provide transparency to users of (and contributors to) this software tool.

このドキュメントでは、RIPE NCC RPKI Validatorバージョン2.25の実装方法について説明します。このソフトウェアのソースコードは[rpki-validator]にあります。このドキュメントの目的は、このソフトウェアツールのユーザー（および貢献者）に透明性を提供することです。

In order to use information published in RPKI repositories, Relying Parties (RPs) need to retrieve and validate the content of certificates, Certificate Revocation Lists (CRLs), and other RPKI signed objects. To validate a particular object, one must ensure that all certificates in the certificate chain up to the Trust Anchor (TA) are valid. Therefore, the validation of a certificate tree is performed top-down, starting from the TA certificate and descending the certificate chain, validating every encountered certificate and its products. The result of this process is a list of all encountered RPKI objects with a validity status attached to each of them. These results may later be used by an RP in making routing decisions, etc.

RPKIリポジトリで公開された情報を使用するには、証明書利用者（RP）が証明書、証明書失効リスト（CRL）、およびその他のRPKI署名付きオブジェクトのコンテンツを取得して検証する必要があります。特定のオブジェクトを検証するには、トラストアンカー（TA）までの証明書チェーン内のすべての証明書が有効であることを確認する必要があります。したがって、証明書ツリーの検証は、TA証明書から開始して証明書チェーンを降順にトップダウンで実行され、検出されたすべての証明書とその製品が検証されます。このプロセスの結果は、検出されたすべてのRPKIオブジェクトのリストであり、それぞれに有効性ステータスが付加されています。これらの結果は、ルーティングの決定などを行うときにRPによって後で使用される場合があります。

Traditionally, RPKI data is made available to RPs through the repositories [RFC6481] accessible over the rsync protocol [rsync]. RPs are advised to keep a local copy of repository data and perform regular updates of this copy from the repository (see Section 5 of [RFC6481]). The RRDP [RFC8182] introduces another method to fetch repository data and keep the local copy up to date with the repository.

従来、RPKIデータは、rsyncプロトコル[rsync]を介してアクセス可能なリポジトリ[RFC6481]を介してRPが利用できるようになっています。 RPは、リポジトリデータのローカルコピーを保持し、このコピーをリポジトリから定期的に更新することをお勧めします（[RFC6481]のセクション5を参照）。 RRDP [RFC8182]は、リポジトリデータをフェッチし、ローカルコピーをリポジトリで最新に保つ別の方法を導入します。

This document describes how the RIPE NCC RPKI Validator discovers RPKI objects to download, builds certificate paths, and validates RPKI objects, independently of what repository access protocol is used. To achieve this, it puts downloaded RPKI objects in an object store, where each RPKI object can be found by its URI, the hash of its content, the value of its Authority Key Identifier (AKI) extension, or a combination of these. It also keeps track of the download and validation time for every object, to decide which locally stored objects are not used in the RPKI tree validation and could be removed.

このドキュメントでは、どのリポジトリアクセスプロトコルが使用されているかに関係なく、RIPE NCC RPKI ValidatorがダウンロードするRPKIオブジェクトを検出し、証明書パスを構築し、RPKIオブジェクトを検証する方法について説明します。これを実現するために、ダウンロードしたRPKIオブジェクトをオブジェクトストアに配置します。各RPKIオブジェクトは、URI、そのコンテンツのハッシュ、Authority Key Identifier（AKI）拡張の値、またはこれらの組み合わせによって見つけることができます。また、すべてのオブジェクトのダウンロードおよび検証時間を追跡し、ローカルに保存されているオブジェクトのうち、RPKIツリーの検証で使用されず、削除できるものを決定します。

2. General Considerations

2. 一般的な考慮事項

2.1. Hash Comparisons

2.1. ハッシュ比較

This algorithm relies on the collision resistance properties of the hash algorithm (defined in [RFC7935]) to compute the hash of repository objects. It assumes that any two objects for which the hash value is the same are identical.

このアルゴリズムは、リポジトリオブジェクトのハッシュを計算するために、ハッシュアルゴリズム（[RFC7935]で定義）の衝突耐性プロパティに依存しています。ハッシュ値が同じである2つのオブジェクトは同一であると想定しています。

The hash comparison is used when matching objects in the repository with entries on the manifest (Section 3.2.2) and when looking up objects in the object store (Section 5).

ハッシュ比較は、リポジトリ内のオブジェクトをマニフェストのエントリと照合する場合（セクション3.2.2）、およびオブジェクトストア内のオブジェクトを検索する場合（セクション5）に使用されます。

2.2. Discovery of RPKI Objects Issued by a CA

2.2. CAが発行したRPKIオブジェクトの検出

There are several possible ways of discovering potential products of a Certification Authority (CA) certificate: one could 1) use all objects located in a repository directory designated as a publication point for a CA, 2) only use objects mentioned on the manifest located at that publication point (see Section 6 of [RFC6486]), or 3) use all known repository objects whose AKI extension matches the Subject Key Identifier (SKI) extension (Section 4.2.1 of [RFC5280]) of a CA certificate.

証明機関（CA）証明書の潜在的な製品を検出する方法はいくつかあります。1）CAの公開ポイントとして指定されたリポジトリディレクトリにあるすべてのオブジェクトを使用する、2）にあるマニフェストに記載されているオブジェクトのみを使用するその公開ポイント（[RFC6486]のセクション6を参照）、または3）CA証明書のサブジェクトキー識別子（SKI）拡張（[RFC5280]のセクション4.2.1）とAKI拡張が一致するすべての既知のリポジトリオブジェクトを使用します。

For publication points whose content is consistent with the manifest and issuing certificate, all of these approaches should produce the same result. For inconsistent publication points, the results might be different. Section 6 of [RFC6486] leaves the decision on how to deal with inconsistencies to a local policy.

内容がマニフェストおよび発行証明書と一致する公開ポイントの場合、これらのアプローチはすべて同じ結果をもたらすはずです。一貫性のない公開ポイントの場合、結果は異なる場合があります。 [RFC6486]のセクション6は、不整合に対処する方法の決定をローカルポリシーに委ねています。

The implementation described here does not rely on content of repository directories but uses the Authority Key Identifier (AKI) extension of a manifest and a CRL to find in an object store (Section 5) a manifest and a CRL issued by a particular CA (see Section 3.2.1). It further uses the hashes of the manifest's fileList entries (Section 4.2.1 of [RFC6486]) to find other objects issued by the CA, as described in Section 3.2.2.

ここで説明する実装は、リポジトリディレクトリのコンテンツに依存しませんが、マニフェストとCRLの認証局識別子（AKI）拡張を使用して、オブジェクトストア（セクション5）で特定のCAによって発行されたマニフェストとCRLを見つけます（参照）セクション3.2.1）。さらに、マニフェストのfileListエントリのハッシュ（[RFC6486]のセクション4.2.1）を使用して、CAが発行した他のオブジェクトを検索します（セクション3.2.2を参照）。

2.3. Manifest Entries versus Repository Content

2.3. マニフェストエントリとリポジトリコンテンツ

Since the current set of RPKI standards (see [RFC6481], [RFC6486], and [RFC6487]) requires use of the manifest [RFC6486] to describe the content of a publication point, this implementation requires strict consistency between the publication point content and manifest content. (This is a more stringent requirement than established in [RFC6486].) Therefore, it will not process objects that are found in the publication point but do not match any of the entries of that publication point's manifest (see Section 3.2.2). It will also issue warnings for all found mismatches, so that the responsible operators could be made aware of inconsistencies and fix them.

RPKI標準の現在のセット（[RFC6481]、[RFC6486]、および[RFC6487]を参照）では、公開ポイントのコンテンツを説明するためにマニフェスト[RFC6486]を使用する必要があるため、この実装では、公開ポイントのコンテンツとマニフェストコンテンツ。（これは[RFC6486]で確立されたものよりも厳しい要件です。）したがって、公開ポイントで見つかったが、その公開ポイントのマニフェストのどのエントリとも一致しないオブジェクトは処理しません（セクション3.2.2を参照）。また、見つかったすべての不一致に対して警告を発行するため、責任のあるオペレーターは不整合を認識して修正できます。

3. Top-Down Validation of a Single Trust Anchor Certificate Tree

3. 単一のトラストアンカー証明書ツリーのトップダウン検証

When several Trust Anchors are configured, validation of their corresponding certificate trees is performed concurrently and independently from each other. For every configured Trust Anchor, the following steps are performed:

複数のトラストアンカーが構成されている場合、対応する証明書ツリーの検証は、互いに独立して同時に実行されます。構成されているすべてのトラストアンカーについて、次の手順が実行されます。

1. The validation of a TA certificate tree starts from its TA certificate. To retrieve the TA certificate, a Trust Anchor Locator (TAL) object is used, as described in Section 3.1.

1. TA証明書ツリーの検証は、そのTA証明書から始まります。 TA証明書を取得するには、セクション3.1で説明されているように、Trust Anchor Locator（TAL）オブジェクトが使用されます。

2. If the TA certificate is retrieved, it is validated according to Section 7 of [RFC6487] and Section 2.2 of [RFC7730]. Otherwise, the validation of the certificate tree is aborted and an error is issued.

2. TA証明書が取得されると、[RFC6487]のセクション7および[RFC7730]のセクション2.2に従って検証されます。そうでない場合、証明書ツリーの検証は中止され、エラーが発行されます。

3. If the TA certificate is valid, then all its subordinate objects are validated as described in Section 3.2. Otherwise, the validation of the certificate tree is aborted and an error is issued.

3. TA証明書が有効な場合、セクション3.2で説明されているように、すべての下位オブジェクトが検証されます。そうでない場合、証明書ツリーの検証は中止され、エラーが発行されます。

4. For each repository object that was validated during this validation run, the validation timestamp is updated in the object store (see Section 5.1.7).

4. この検証の実行中に検証されたリポジトリオブジェクトごとに、検証タイムスタンプがオブジェクトストアで更新されます（セクション5.1.7を参照）。

5. Outdated objects are removed from the store as described in Section 3.3. This completes the validation of the TA certificate tree.

5. セクション3.3で説明されているように、古いオブジェクトはストアから削除されます。これで、TA証明書ツリーの検証が完了しました。

3.1. Fetching the Trust Anchor Certificate Using the Trust Anchor Locator

3.1. トラストアンカーロケーターを使用したトラストアンカー証明書の取得

The following steps are performed in order to fetch a Trust Anchor certificate:

トラストアンカー証明書を取得するには、次の手順を実行します。

1. (Optional) If the TAL contains a prefetch.uris field, pass the URIs contained in that field to the fetcher (see Section 4.1.1). (This field is a non-standard addition to the TAL format. It helps with fetching non-hierarchical rsync repositories more efficiently.)

1. （オプション）TALにprefetch.urisフィールドが含まれている場合は、そのフィールドに含まれているURIをフェッチャーに渡します（セクション4.1.1を参照）。（このフィールドはTALフォーマットへの非標準の追加です。非階層のrsyncリポジトリをより効率的にフェッチするのに役立ちます。）

2. Extract the first TA certificate URI from the TAL's URI section (see Section 2.1 of [RFC7730]) and pass it to the object fetcher (Section 4.1.2). If the fetcher returns an error, repeat this step for every URI in the URI section until no error is encountered or no more URIs are left.

2. TALのURIセクションから最初のTA証明書URIを抽出し（[RFC7730]のセクション2.1を参照）、それをオブジェクトフェッチャーに渡します（セクション4.1.2）。フェッチャーがエラーを返した場合は、エラーが発生しなくなるか、URIがなくなるまで、URIセクションのすべてのURIに対してこの手順を繰り返します。

3. From the object store (see Section 5.1.3), retrieve all certificate objects for which the URI matches the URI extracted from the TAL in the previous step and the public key matches the subjectPublicKeyInfo extension of the TAL (see Section 2.1 of [RFC7730]).

3. オブジェクトストア（セクション5.1.3を参照）から、URIが前の手順でTALから抽出されたURIと一致し、公開鍵がTALのsubjectPublicKeyInfo拡張と一致するすべての証明書オブジェクトを取得します（[RFC7730]のセクション2.1を参照））。

4. If no such objects are found or if more than one such objects are found, issue an error and abort the certificate tree validation process with an error. Otherwise, use the single found object as the TA certificate.

4. そのようなオブジェクトが見つからない場合、またはそのようなオブジェクトが複数見つかった場合は、エラーを発行し、証明書ツリーの検証プロセスをエラーで中止します。それ以外の場合は、見つかった単一のオブジェクトをTA証明書として使用します。

3.2. CA Certificate Validation

3.2. CA証明書の検証

The following steps describe the validation of a single CA resource certificate:

次の手順では、単一のCAリソース証明書の検証について説明します。

1. If both the caRepository (Section 4.8.8.1 of [RFC6487]) and the id-ad-rpkiNotify (Section 3.2 of [RFC8182]) instances of an accessMethod are present in the Subject Information Access extension of the CA certificate, use a local policy to determine which pointer to use. Extract the URI from the selected pointer and pass it to the object fetcher (that will then fetch all objects available from that repository; see Section 4.1.1).

1. CA証明書のサブジェクト情報アクセス拡張に、accessMethodのcaRepository（[RFC6487]のセクション4.8.8.1）とid-ad-rpkiNotify（[RFC8182]のセクション3.2））の両方のインスタンスが存在する場合は、ローカルポリシーを使用します。使用するポインタを決定します。選択したポインターからURIを抽出し、それをオブジェクトフェッチャーに渡します（リポジトリから利用可能なすべてのオブジェクトをフェッチします。セクション4.1.1を参照してください）。

2. For the CA certificate, find the current manifest and certificate revocation list (CRL) using the procedure described in Section 3.2.1. If no such manifest and CRL could be found, stop validation of this certificate, consider it invalid, and issue an error.

2. CA証明書については、セクション3.2.1で説明されている手順を使用して、現在のマニフェストと証明書失効リスト（CRL）を見つけます。そのようなマニフェストとCRLが見つからない場合は、この証明書の検証を停止し、それを無効と見なしてエラーを発行します。

3. Compare the URI found in the id-ad-rpkiManifest field (Section 4.8.8.1 of [RFC6487]) of the SIA extension of the certificate with the URI of the manifest found in the previous step. If they are different, issue a warning but continue the validation process using the manifest found in the previous step. (This warning indicates that there is a mismatch between the expected and the actual location of an object in a repository. See Section 7.3 for the explanation of this mismatch and the decision made.)

3. 証明書のSIA拡張のid-ad-rpkiManifestフィールド（[RFC6487]のセクション4.8.8.1）にあるURIを、前のステップで見つかったマニフェストのURIと比較します。それらが異なる場合は、警告を発行しますが、前のステップで見つかったマニフェストを使用して検証プロセスを続行します。（この警告は、リポジトリ内のオブジェクトの予想される場所と実際の場所の間に不一致があることを示します。この不一致の説明と決定については、セクション7.3を参照してください。）

4. Perform discovery and validation of manifest entries as described in Section 3.2.2.

4. セクション3.2.2の説明に従って、マニフェストエントリの検出と検証を実行します。

5. Validate all resource certificate objects found on the manifest using the CRL object:

5. CRLオブジェクトを使用して、マニフェストで見つかったすべてのリソース証明書オブジェクトを検証します。

* If the strict validation option is enabled by the operator, the validation is performed according to Section 7 of [RFC6487].

* 厳密な検証オプションがオペレーターによって有効にされている場合、検証は[RFC6487]のセクション7に従って実行されます。

* Otherwise, the validation is performed according to Section 7 of [RFC6487] but with the exception of the resource certification path validation, which is performed according to Section 4.2.4.4 of [RFC8360].

* それ以外の場合、[RFC6487]のセクション7に従って検証が実行されますが、[RFC8360]のセクション4.2.4.4に従って実行されるリソース証明書パス検証は例外です。

(Note that this implementation uses the operator configuration to decide which algorithm to use for path validation. It applies the selected algorithm to all resource certificates, rather than applying an appropriate algorithm per resource certificate based on the object identifier (OID) for the Certificate Policy found in that certificate, as specified in [RFC8360].)

（この実装は、オペレーター構成を使用して、パス検証に使用するアルゴリズムを決定することに注意してください。証明書ポリシーのオブジェクト識別子（OID）に基づいてリソース証明書ごとに適切なアルゴリズムを適用するのではなく、選択したアルゴリズムをすべてのリソース証明書に適用します[RFC8360]で指定されているように、その証明書で見つかります。）

6. Validate all Route Origin Authorization (ROA) objects found on the manifest using the CRL object found on the manifest, according to Section 4 of [RFC6482].

6. [RFC6482]のセクション4に従って、マニフェストにあるCRLオブジェクトを使用して、マニフェストにあるすべてのRoute Origin Authorization（ROA）オブジェクトを検証します。

7. Validate all Ghostbusters Record objects found on the manifest using the CRL object found on the manifest, according to Section 7 of [RFC6493].

7. [RFC6493]のセクション7に従って、マニフェストにあるCRLオブジェクトを使用して、マニフェストにあるすべてのGhostbusters Recordオブジェクトを検証します。

8. For every valid CA certificate object found on the manifest, apply the procedure described in this section, recursively, provided that this CA certificate (identified by its SKI) has not yet been validated during current tree validation run.

8. マニフェストで見つかったすべての有効なCA証明書オブジェクトに対して、このCA証明書（SKIによって識別される）が現在のツリー検証の実行中にまだ検証されていない場合は、このセクションで説明する手順を再帰的に適用します。

3.2.1. Finding the Most Recent Valid Manifest and CRL

3.2.1. 最新の有効なマニフェストとCRLを見つける

To find the most recent issued manifest and CRL objects of a particular CA certificate, the following steps are performed:

特定のCA証明書の最新の発行済みマニフェストとCRLオブジェクトを見つけるには、次の手順を実行します。

1. From the store (see Section 5.1.4), fetch all objects of type manifest whose certificate's AKI extension matches the SKI of the current CA certificate. If no such objects are found, stop processing the current CA certificate and issue an error.

1. ストア（セクション5.1.4を参照）から、証明書のAKI拡張が現在のCA証明書のSKIと一致するマニフェストタイプのすべてのオブジェクトをフェッチします。そのようなオブジェクトが見つからない場合は、現在のCA証明書の処理を停止し、エラーを発行します。

2. Among found objects, find the manifest object with the highest manifestNumber field (Section 4.2.1 of [RFC6486]) for which all following conditions are met:

2. 見つかったオブジェクトの中から、manifestNumberフィールド（[RFC6486]のセクション4.2.1）が最も高く、次のすべての条件を満たすマニフェストオブジェクトを見つけます。

* There is only one entry in the manifest for which the store contains exactly one object of type CRL, the hash of which matches the hash of the entry.

* ストアにCRLタイプのオブジェクトが1つだけ含まれるエントリがマニフェストに1つだけあり、そのハッシュはエントリのハッシュと一致しています。

* The manifest's certificate AKI equals the above CRL's AKI.

* マニフェストの証明書AKIは、上記のCRLのAKIと同じです。

* The above CRL is a valid object according to Section 6.3 of [RFC5280].

* 上記のCRLは、[RFC5280]のセクション6.3によると有効なオブジェクトです。

* The manifest is a valid object according to Section 4.4 of [RFC6486], and its EE certificate is not in the CRL found above.

* [RFC6486]のセクション4.4によると、マニフェストは有効なオブジェクトであり、そのEE証明書は上記のCRLにありません。

3. If there is an object that matches the above criteria, consider this object to be the valid manifest, and consider the CRL found at the previous step to be the valid CRL for the current CA certificate's publication point.

3. 上記の基準に一致するオブジェクトがある場合は、このオブジェクトを有効なマニフェストと見なし、前の手順で見つかったCRLを現在のCA証明書の公開ポイントの有効なCRLと見なします。

4. Report an error for every other manifest with a number higher than the number of the valid manifest.

4. 有効なマニフェストの番号よりも大きい番号を持つ他のすべてのマニフェストのエラーを報告します。

3.2.2. Validating Manifest Entries

3.2.2. マニフェストエントリの検証

For every entry in the manifest object:

マニフェストオブジェクトのすべてのエントリ：

1. Construct an entry's URI by appending the entry name to the current CA's publication point URI.

1. 現在のCAの公開ポイントURIにエントリ名を追加して、エントリのURIを構築します。

2. Get all objects from the store whose hash attribute equals the entry's hash (see Section 5.1.2).

2. ハッシュ属性がエントリのハッシュと等しいストアからすべてのオブジェクトを取得します（セクション5.1.2を参照）。

3. If no such objects are found, issue an error for this manifest entry and progress to the next entry. This case indicates that the repository does not have an object at the location listed in the manifest or that the object's hash does not match the hash listed in the manifest.

3. そのようなオブジェクトが見つからない場合は、このマニフェストエントリに対してエラーを発行し、次のエントリに進みます。このケースは、リポジトリのマニフェストにリストされている場所にオブジェクトがないか、オブジェクトのハッシュがマニフェストにリストされているハッシュと一致しないことを示しています。

4. For every found object, compare its URI with the URI of the manifest entry.

4. 見つかったすべてのオブジェクトについて、そのURIをマニフェストエントリのURIと比較します。

* For every object with a non-matching URI, issue a warning. This case indicates that the object from the manifest entry is (also) found at a different location in a (possibly different) repository.

* 一致しないURIを持つすべてのオブジェクトに対して、警告を発行します。このケースは、マニフェストエントリのオブジェクトが、（場合によっては）リポジトリの別の場所にあることも示しています。

* If no objects with a matching URI are found, issue a warning. This case indicates that there is no object found in the repository at the location listed in the manifest entry (but there is at least one matching object found at a different location).

* 一致するURIを持つオブジェクトが見つからない場合は、警告を発行します。このケースは、マニフェストエントリにリストされている場所のリポジトリでオブジェクトが見つからないことを示しています（ただし、別の場所で少なくとも1つの一致するオブジェクトが見つかりました）。

5. Use all found objects for further validation as per Section 3.2.

5. セクション3.2のように、見つかったすべてのオブジェクトをさらに検証するために使用します。

Please note that the above steps will not reject objects whose hash matches the hash listed in the manifest but whose URI does not. See Section 7.3 for additional information.

上記の手順では、マニフェストにリストされているハッシュと一致するが、URIが一致しないオブジェクトは拒否されません。詳細については、セクション7.3を参照してください。

3.3. Object Store Cleanup

3.3. オブジェクトストアのクリーンアップ

At the end of every TA tree validation, some objects are removed from the store using the following rules:

すべてのTAツリー検証の最後に、次のルールを使用して一部のオブジェクトがストアから削除されます。

1. Given all objects that were encountered during the current validation run, remove from the store (Section 5.1.6) all objects whose URI attribute matches the URI of one of the encountered objects but whose content's hash does not match the hash of any of the encountered objects. This removes from the store objects that were replaced in the repository by their newer versions with the same URIs.

1. 現在の検証の実行中に検出されたすべてのオブジェクトを指定して、ストアから削除します（セクション5.1.6）。URI属性が検出されたオブジェクトのいずれかのURIと一致するが、コンテンツのハッシュが検出されたいずれのハッシュとも一致しないすべてのオブジェクトオブジェクト。これにより、リポジトリ内で同じURIを持つ新しいバージョンに置き換えられたオブジェクトがストアから削除されます。

2. Remove from the store all objects that were last encountered during validation a long time ago (as specified by the local policy). This removes objects that do not appear on any valid manifest anymore (but possibly are still published in a repository).

2. （ローカルポリシーで指定されているように）妥当性検査中に最後に検出されたすべてのオブジェクトをストアから削除します。これにより、有効なマニフェストに表示されなくなったオブジェクトが削除されます（ただし、リポジトリにまだ公開されている可能性があります）。

3. Remove from the store all objects that were downloaded recently (as specified by the local policy) but that have never been used in the validation process. This removes objects that have never appeared on any valid manifest.

3. 最近ダウンロードされた（ローカルポリシーで指定されている）が、検証プロセスで使用されていないすべてのオブジェクトをストアから削除します。これにより、有効なマニフェストに表示されたことのないオブジェクトが削除されます。

Shortening the time interval used in step 2 will free more disk space used by the store, at the expense of downloading removed objects again if they are still published in the repository.

手順2で使用した時間間隔を短くすると、ストアで使用されているディスク領域が解放されます。ただし、削除されたオブジェクトがリポジトリにまだ公開されている場合、それらを再度ダウンロードする必要があります。

Extending the time interval used in step 3 will prevent repeated downloads of unused repository objects. However, it will also extend the interval at which unused objects are removed. This creates a risk that such objects will fill up all available disk space if a large enough amount of such objects is published in the repository (either by mistake or with a malicious intent).

手順3で使用される時間間隔を延長すると、未使用のリポジトリオブジェクトが繰り返しダウンロードされるのを防ぐことができます。ただし、未使用のオブジェクトが削除される間隔も長くなります。これにより、そのようなオブジェクトが（誤って、または悪意のある目的で）リポジトリに公開された場合、そのようなオブジェクトが利用可能なすべてのディスク領域をいっぱいにするリスクがあります。

4. Remote Objects Fetcher

4. リモートオブジェクトフェッチャー

The fetcher is responsible for downloading objects from remote repositories (described in Section 3 of [RFC6481]) using the rsync protocol [rsync] or RRDP [RFC8182].

フェッチャーは、rsyncプロトコル[rsync]またはRRDP [RFC8182]を使用して、リモートリポジトリ（[RFC6481]のセクション3で説明）からオブジェクトをダウンロードします。

4.1. Fetcher Operations

4.1. フェッチャー操作

For every visited URI, the fetcher keeps track of the last time a successful fetch occurred.

訪問したすべてのURIについて、フェッチャーは正常にフェッチが行われた最後の時刻を追跡します。

4.1.1. Fetch Repository Objects

4.1.1. リポジトリオブジェクトのフェッチ

This operation receives one parameter -- a URI. For an rsync repository, this URI points to a directory. For an RRDP repository, it points to the repository's notification file.

このオペレーションは、1つのパラメーター（URI）を受け取ります。 rsyncリポジトリの場合、このURIはディレクトリを指します。 RRDPリポジトリの場合、リポジトリの通知ファイルを指します。

The fetcher follows these steps:

フェッチャーは次の手順に従います。

1. If data associated with the URI has been downloaded recently (as specified by the local policy), skip the following steps.

1. URIに関連付けられたデータが最近ダウンロードされた場合（ローカルポリシーで指定されているとおり）、次の手順をスキップします。

2. Download remote objects using the URI provided (for an rsync repository, use recursive mode). If the URI contains the "https" schema and download has failed, issue a warning, replace the "https" schema in the URI with "http", and try to download objects again using the resulting URI.

2. 提供されたURIを使用してリモートオブジェクトをダウンロードします（rsyncリポジトリの場合は、再帰モードを使用します）。 URIに「https」スキーマが含まれていてダウンロードが失敗した場合は、警告を発行し、URIの「https」スキーマを「http」に置き換え、結果のURIを使用してオブジェクトのダウンロードを再試行します。

3. If remote objects cannot be downloaded, issue an error and skip the following steps.

3. リモートオブジェクトをダウンロードできない場合は、エラーを発行して次の手順をスキップします。

4. Perform syntactic verification of fetched objects. The type of every object (certificate, manifest, CRL, ROA, or Ghostbusters Record) is determined based on the object's filename extension (.cer, .mft, .crl, .roa, and .gbr, respectively). The syntax of the object is described in Section 4 of [RFC6487] for resource certificates, step 1 of Section 3 of [RFC6488] for signed objects, Section 4 of [RFC6486] for manifests, [RFC5280] for CRLs, Section 3 of [RFC6482] for ROAs, and Section 5 of [RFC6493] for Ghostbusters Records.

4. フェッチされたオブジェクトの構文検証を実行します。すべてのオブジェクトのタイプ（証明書、マニフェスト、CRL、ROA、またはゴーストバスターズレコード）は、オブジェクトのファイル名拡張子（それぞれ、.cer、.mft、.crl、.roa、および.gbr）に基づいて決定されます。オブジェクトの構文は、リソース証明書については[RFC6487]のセクション4、署名付きオブジェクトについては[RFC6488]のセクション3のステップ1、マニフェストについては[RFC6486]のセクション4、CRLについては[RFC5280]、[ ROAについてはRFC6482]、ゴーストバスターズレコードについては[RFC6493]のセクション5。

5. Put every downloaded and syntactically correct object in the object store (Section 5.1.1).

5. ダウンロードしたすべての構文的に正しいオブジェクトをオブジェクトストアに配置します（セクション5.1.1）。

The time interval used in step 1 should be chosen based on the acceptable delay in receiving repository updates.

手順1で使用する時間間隔は、リポジトリの更新を受信する際の許容可能な遅延に基づいて選択する必要があります。

4.1.2. Fetch Single Repository Object

4.1.2. 単一のリポジトリオブジェクトの取得

This operation receives one parameter -- a URI that points to an object in a repository.

この操作は、1つのパラメーター（リポジトリー内のオブジェクトを指すURI）を受け取ります。

The fetcher follows these steps:

フェッチャーは次の手順に従います。

1. Download a remote object using the URI provided. If the URI contains the "https" schema and download failed, issue a warning, replace the "https" schema in the URI with "http", and try to download the object using the resulting URI.

1. 提供されたURIを使用してリモートオブジェクトをダウンロードします。 URIに「https」スキーマが含まれていてダウンロードが失敗した場合は、警告を発行し、URIの「https」スキーマを「http」に置き換え、結果のURIを使用してオブジェクトをダウンロードしてみます。

2. If the remote object cannot be downloaded, issue an error and skip the following steps.

2. リモートオブジェクトをダウンロードできない場合は、エラーを発行して次の手順をスキップします。

3. Perform syntactic verification of the fetched object. The type of object (certificate, manifest, CRL, ROA, or Ghostbusters Record) is determined based on the object's filename extension (.cer, .mft, .crl, .roa, and .gbr, respectively). The syntax of the object is described in Section 4 of [RFC6487] for resource certificates, step 1 of Section 3 of [RFC6488] for signed objects, Section 4 of [RFC6486] for manifests, [RFC5280] for CRLs, Section 3 of [RFC6482] for ROAs, and Section 5 of [RFC6493] for Ghostbusters Records.

3. フェッチされたオブジェクトの構文検証を実行します。オブジェクトのタイプ（証明書、マニフェスト、CRL、ROA、またはゴーストバスターズレコード）は、オブジェクトのファイル名拡張子（それぞれ.cer、.mft、.crl、.roa、および.gbr）に基づいて決定されます。オブジェクトの構文は、リソース証明書については[RFC6487]のセクション4、署名付きオブジェクトについては[RFC6488]のセクション3のステップ1、マニフェストについては[RFC6486]のセクション4、CRLについては[RFC5280]、[ ROAについてはRFC6482]、ゴーストバスターズレコードについては[RFC6493]のセクション5。

4. If the downloaded object is not syntactically correct, issue an error and skip further steps.

4. ダウンロードしたオブジェクトが構文的に正しくない場合は、エラーを発行し、以降の手順をスキップします。

5. Delete all objects from the object store (Section 5.1.5) whose URI matches the URI given.

5. 指定されたURIにURIが一致するすべてのオブジェクトをオブジェクトストア（セクション5.1.5）から削除します。

6. Put the downloaded object in the object store (Section 5.1.1).

6. ダウンロードしたオブジェクトをオブジェクトストアに配置します（セクション5.1.1）。

5. Local Object Store

5. ローカルオブジェクトストア

5.1. Store Operations

5.1. 店舗運営

5.1.1. Store Repository Object

5.1.1. リポジトリオブジェクトの保存

Put the given object in the store if there is no record with the same hash and URI fields. Note that in the (unlikely) event of hash collision, the given object will not replace the object in the store.

同じハッシュフィールドとURIフィールドを持つレコードがない場合は、指定されたオブジェクトをストアに配置します。ハッシュ衝突の（ありそうにない）イベントでは、指定されたオブジェクトはストア内のオブジェクトを置き換えないことに注意してください。

5.1.2. Get Objects by Hash

5.1.2. ハッシュによるオブジェクトの取得

Retrieve all objects from the store whose hash attribute matches the given hash.

指定されたハッシュに一致するハッシュ属性を持つストアからすべてのオブジェクトを取得します。

5.1.3. Get Certificate Objects by URI

5.1.3. URIによる証明書オブジェクトの取得

Retrieve from the store all objects of type certificate whose URI attribute matches the given URI.

URI属性が指定されたURIと一致するタイプの証明書のすべてのオブジェクトをストアから取得します。

5.1.4. Get Manifest Objects by AKI

5.1.4. AKIによるマニフェストオブジェクトの取得

Retrieve from the store all objects of type manifest whose AKI attribute matches the given AKI.

AKI属性が指定されたAKIと一致するマニフェストタイプのすべてのオブジェクトをストアから取得します。

5.1.5. Delete Objects for a URI

5.1.5. URIのオブジェクトを削除する

For a given URI, delete all objects in the store with a matching URI attribute.

指定されたURIについて、一致するURI属性を持つストア内のすべてのオブジェクトを削除します。

5.1.6. Delete Outdated Objects

5.1.6. 古いオブジェクトを削除する

For a given URI and a list of hashes, delete all objects in the store with a matching URI whose hash attribute is not in the given list of hashes.

特定のURIおよびハッシュのリストについて、ハッシュ属性が特定のハッシュのリストにない、一致するURIを持つストア内のすべてのオブジェクトを削除します。

5.1.7. Update Object's Validation Time

5.1.7. オブジェクトの検証時間を更新する

For all objects in the store whose hash attribute matches the given hash, set the last validation time attribute to the given timestamp.

ハッシュ属性が特定のハッシュと一致するストア内のすべてのオブジェクトについて、最終検証時間属性を特定のタイムスタンプに設定します。

6. IANA Considerations

6. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

7. Security Considerations

7. セキュリティに関する考慮事項

7.1. Hash Collisions

7.1. ハッシュ衝突

This implementation will not detect possible hash collisions in the hashes of repository objects (calculated using the file hash algorithm specified in [RFC7935]). It considers objects with same hash values to be identical.

この実装は、リポジトリオブジェクトのハッシュで起こり得るハッシュの衝突を検出しません（[RFC7935]で指定されたファイルハッシュアルゴリズムを使用して計算されます）。同じハッシュ値を持つオブジェクトは同一であると見なします。

7.2. Algorithm Agility

7.2. アルゴリズムの俊敏性

This implementation only supports hash algorithms and key sizes specified in [RFC7935]. Algorithm agility described in [RFC6916] is not supported.

この実装は、[RFC7935]で指定されたハッシュアルゴリズムとキーサイズのみをサポートします。 [RFC6916]で説明されているアルゴリズムの俊敏性はサポートされていません。

7.3. Mismatch between the Expected and Actual Location of an Object in the Repository

7.3. リポジトリ内のオブジェクトの予想される場所と実際の場所の不一致

According to Section 2 of [RFC6481], all objects issued by a particular CA certificate are expected to be located in one repository publication point, specified in the SIA extension of that CA certificate. The manifest object issued by that CA certificate enumerates all other issued objects, listing their filenames and content hashes.

[RFC6481]のセクション2によると、特定のCA証明書によって発行されたすべてのオブジェクトは、そのCA証明書のSIA拡張で指定された1つのリポジトリ公開ポイントにあることが想定されています。そのCA証明書によって発行されたマニフェストオブジェクトは、他のすべての発行済みオブジェクトを列挙し、それらのファイル名とコンテンツハッシュをリストします。

However, it is possible that an object whose content hash matches the hash listed in the manifest either has a different filename or is located at a different publication point in a repository.

ただし、コンテンツハッシュがマニフェストにリストされているハッシュと一致するオブジェクトは、ファイル名が異なるか、リポジトリの別の公開ポイントにある可能性があります。

On the other hand, all RPKI objects, either explicitly or within their embedded EE certificate, have an AKI extension that contains the key identifier of their issuing CA certificate. Therefore, it is always possible to perform an RPKI validation of the object whose expected location does not match its actual location, provided that the certificate that matches the AKI of the object in question is known to the system that performs validation.

一方、すべてのRPKIオブジェクトには、明示的または埋め込まれたEE証明書内のいずれかで、発行元のCA証明書のキー識別子を含むAKI拡張があります。したがって、問題のオブジェクトのAKIと一致する証明書が検証を実行するシステムに認識されている場合、予想される場所が実際の場所と一致しないオブジェクトのRPKI検証を実行することは常に可能です。

In the case of a mismatch as described above, this implementation will not exclude an object from further validation merely because its actual location or filename does not match the expected location or filename. This decision was made because the actual location of a file in a repository is taken from the repository retrieval mechanism, which, in the case of an rsync repository, does not provide any cryptographic security, and in the case of an RRDP repository, provides only a transport-layer security with the fallback to unsecured transport. On the other hand, the manifest is an RPKI signed object, and its content could be verified in the context of the RPKI validation.

上記の不一致の場合、実際の場所またはファイル名が予期される場所またはファイル名と一致しないという理由だけで、この実装はオブジェクトを以降の検証から除外しません。この決定が行われたのは、リポジトリ内のファイルの実際の場所が、rsyncリポジトリの場合は暗号セキュリティを提供せず、RRDPリポジトリの場合のみ提供するリポジトリ取得メカニズムから取得されるためです。安全でないトランスポートへのフォールバックを備えたトランスポート層セキュリティ。一方、マニフェストはRPKI署名付きオブジェクトであり、その内容はRPKI検証のコンテキストで検証できます。

7.4. Manifest Content versus Publication Point Content

7.4. マニフェストコンテンツとパブリケーションポイントコンテンツ

This algorithm uses the content of a manifest object to determine other objects issued by a CA certificate. It verifies that the manifest is located in the publication point designated in the CA certificate's SIA extension. However, if there are other (not listed in the manifest) objects located in the same publication point directory, they are ignored even if they might be valid and issued by the same CA as the manifest. (This RP behavior is allowed, but not required, by [RFC6486].)

このアルゴリズムは、マニフェストオブジェクトのコンテンツを使用して、CA証明書によって発行された他のオブジェクトを決定します。マニフェストがCA証明書のSIA拡張で指定された公開ポイントにあることを確認します。ただし、同じ公開ポイントディレクトリに他の（マニフェストにリストされていない）オブジェクトが存在する場合、それらが有効であり、マニフェストと同じCAによって発行されている場合でも無視されます。（このRP動作は[RFC6486]によって許可されていますが、必須ではありません。）

7.5. Possible Denial of Service

7.5. サービス拒否の可能性

The store cleanup procedure described in Section 3.3 tries to minimize removal and subsequent re-fetch of objects that are published in a repository but not used in the validation. Once such objects are removed from the remote repository, they will be discarded from the local object store after a period of time specified by a local policy. By generating an excessive amount of syntactically valid RPKI objects, a man-in-the-middle attack between a validating tool and a repository could force an implementation to fetch and store those objects in the object store (see Section 4.1.1) before they are validated and discarded, leading to out-of-memory or out-of-disk-space conditions and, subsequently, a denial of service.

セクション3.3で説明されているストアのクリーンアップ手順では、リポジトリで公開されているが検証では使用されないオブジェクトの削除とその後の再フェッチを最小限に抑えようとします。このようなオブジェクトがリモートリポジトリから削除されると、ローカルポリシーで指定された時間が経過すると、ローカルオブジェクトストアから破棄されます。構文的に有効なRPKIオブジェクトを過剰に生成することにより、検証ツールとリポジトリの間の中間者攻撃により、実装がそれらのオブジェクトをフェッチしてオブジェクトストア（セクション4.1.1を参照）に保存する前に、それらのオブジェクトを強制的に保存できます。検証および破棄され、メモリ不足またはディスク領域不足の状態が発生し、続いてサービス拒否が発生します。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.

[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、DOI 10.17487 / RFC6481、2012年2月、<https：//www.rfc-editor。 org / info / rfc6481>。

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.

[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「A Route for Route Origin Authorizations（ROAs）」、RFC 6482、DOI 10.17487 / RFC6482、2012年2月、<https：//www.rfc- editor.org/info/rfc6482>。

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>.

[RFC6486] Austein、R.、Huston、G.、Kent、S。、およびM. Lepinski、「Manifests for the Resource Public Key Infrastructure（RPKI）」、RFC 6486、DOI 10.17487 / RFC6486、2012年2月、<https： //www.rfc-editor.org/info/rfc6486>。

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.

[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、DOI 10.17487 / RFC6487、2012年2月、<https：//www.rfc- editor.org/info/rfc6487>。

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <https://www.rfc-editor.org/info/rfc6488>.

[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「Resource Public Key Infrastructure（RPKI）の署名済みオブジェクトテンプレート」、RFC 6488、DOI 10.17487 / RFC6488、2012年2月、<https：// www .rfc-editor.org / info / rfc6488>。

[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, <https://www.rfc-editor.org/info/rfc6493>.

[RFC6493] Bush、R。、「The Resource Public Key Infrastructure（RPKI）Ghostbusters Record」、RFC 6493、DOI 10.17487 / RFC6493、2012年2月、<https://www.rfc-editor.org/info/rfc6493>。

[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <https://www.rfc-editor.org/info/rfc6916>.

[RFC6916]ガリアーノ、R。、ケント、S。、およびS.ターナー、「リソース公開鍵インフラストラクチャ（RPKI）のアルゴリズムの俊敏性手順」、BCP 182、RFC 6916、DOI 10.17487 / RFC6916、2013年4月、<https： //www.rfc-editor.org/info/rfc6916>。

[RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, <https://www.rfc-editor.org/info/rfc7730>.

[RFC7730] Huston、G.、Weiler、S.、Michaelson、G。、およびS. Kent、「Resource Public Key Infrastructure（RPKI）Trust Anchor Locator」、RFC 7730、DOI 10.17487 / RFC7730、2016年1月、<https： //www.rfc-editor.org/info/rfc7730>。

[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>.

[RFC7935] Huston、G。およびG. Michaelson、編、「リソースの公開鍵インフラストラクチャで使用するアルゴリズムと鍵サイズのプロファイル」、RFC 7935、DOI 10.17487 / RFC7935、2016年8月、<https：// www .rfc-editor.org / info / rfc7935>。

[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <https://www.rfc-editor.org/info/rfc8182>.

[RFC8182] Bruijnzeels、T.、Muravskiy、O.、Weber、B。、およびR. Austein、「The RPKI Repository Delta Protocol（RRDP）」、RFC 8182、DOI 10.17487 / RFC8182、2017年7月、<https：// www.rfc-editor.org/info/rfc8182>。

[RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., Newton, A., and D. Shaw, "Resource Public Key Infrastructure (RPKI) Validation Reconsidered", RFC 8360, DOI 10.17487/RFC8360, April 2018, <https://www.rfc-editor.org/info/rfc8360>.

[RFC8360] Huston、G.、Michaelson、G.、Martinez、C.、Bruijnzeels、T.、Newton、A。、およびD. Shaw、「Resource Public Key Infrastructure（RPKI）Validation Reconsidered」、RFC 8360、DOI 10.17487 / RFC8360、2018年4月、<https://www.rfc-editor.org/info/rfc8360>。

8.2. Informative References

8.2. 参考引用

[rpki-validator] "RIPE-NCC/rpki-validator source code", <https://github.com/RIPE-NCC/rpki-validator>.

[rpki-validator]「RIPE-NCC / rpki-validator source code」、<https://github.com/RIPE-NCC/rpki-validator>。

[rsync] "rsync", October 2018, <https://rsync.samba.org>.

[rsync]「rsync」、2018年10月、<https://rsync.samba.org>。

Acknowledgements

謝辞

This document describes the algorithm as it is implemented by the software development team at the RIPE NCC, which, over time, included Mikhail Puzanov, Erik Rozendaal, Miklos Juhasz, Misja Alma, Thiago da Cruz Pereira, Yannis Gonianakis, Andrew Snare, Varesh Tapadia, Paolo Milani, Thies Edeling, Hans Westerbeek, Rudi Angela, and Constantijn Visinescu. The authors would also like to acknowledge contributions by Carlos Martinez, Andy Newton, Rob Austein, and Stephen Kent.

このドキュメントでは、RIPE NCCのソフトウェア開発チームによって実装されたアルゴリズムについて説明します。これには、ミハイルプザノフ、エリックロゼンダール、ミクロスジュハス、ミシャアルマ、チアゴダクルスペレイラ、ヤニスゴニアナキス、アンドリュースネア、ヴァレシュタパディアが含まれます。、Paolo Milani、Thies Edeling、Hans Westerbeek、Rudi Angela、およびConstantijn Visinescu。著者はまた、Carlos Martinez、Andy Newton、Rob Austein、およびStephen Kentによる寄稿を認めたいと思います。

Authors' Addresses

著者のアドレス

Oleg Muravskiy RIPE NCC

オレグムラフスキーRIPE NCC

   Email: oleg@ripe.net
   URI:   https://www.ripe.net/

Tim Bruijnzeels NLnet Labs

   Email: tim@nlnetlabs.nl
   URI:   https://www.nlnetlabs.nl/