[要約] RFC 6916は、RPKIのアルゴリズムの柔軟性手順に関するものであり、RPKIのセキュリティアルゴリズムの変更手続きを定義しています。目的は、RPKIのアルゴリズムを柔軟に変更するための手順を提供し、セキュリティの向上と将来の技術の進化に対応することです。
Internet Engineering Task Force (IETF) R. Gagliano
Request for Comments: 6916 Cisco Systems
BCP: 182 S. Kent
Category: Best Current Practice BBN Technologies
ISSN: 2070-1721 S. Turner
IECA, Inc.
April 2013
Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)
リソース公開鍵インフラストラクチャ（RPKI）のアルゴリズム俊敏性手順
Abstract
概要
This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children).
このドキュメントでは、リソース公開鍵インフラストラクチャ（RPKI）に参加している認証局（CA）と証明書利用者（RP）が、新しい（そしておそらく暗号学的に強力な）アルゴリズムセットに移行するために従う必要があるプロセスを指定します。プロセスは数年の時間スケールで完了する予定です。したがって、緊急遷移は指定されていません。このドキュメントで定義されている移行手順は、トップダウンの移行のみをサポートします（親は子の前に移行します）。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化しています。
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 BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc6916.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6916で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Key Rollover Steps for Algorithm Migration . . . . . . . . . . 6
4.1. Milestones Definition . . . . . . . . . . . . . . . . . . 6
4.2. Process Overview . . . . . . . . . . . . . . . . . . . . . 7
4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 9
4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 14
5. Support for Multiple Algorithms in the RPKI Provisioning
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Validation of Multiple Instances of Signed Products . . . . . 15
7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Key Rollover . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Repository Structure . . . . . . . . . . . . . . . . . . . . . 17
10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. Normative References . . . . . . . . . . . . . . . . . . . . . 19
The Resource Public Key Infrastructure (RPKI) must accommodate transitions between the public keys used by Certification Authorities (CAs). Transitions of this sort are usually termed "key rollover". Planned key rollover will occur regularly throughout the life of the RPKI, as each CA changes its public keys, in a non-coordinated fashion. (By non-coordinated we mean that the time at which each CA elects to change its keys is locally determined, not coordinated across the RPKI.) Moreover, because a key change might be necessitated by suspected private key compromise, one can never assume coordination of these events among all of the CAs in the RPKI. In an emergency key rollover, the old certificate is revoked and a new certificate with a new key is issued. The mechanisms to perform a key rollover in RPKI (either planned or in an emergency), while maintaining the same algorithm suite, are covered in [RFC6489].
リソース公開鍵インフラストラクチャ（RPKI）は、証明機関（CA）が使用する公開鍵間の遷移に対応する必要があります。この種の遷移は、通常「キーロールオーバー」と呼ばれます。各CAが調整されていない方法で公開鍵を変更すると、計画された鍵のロールオーバーがRPKIの存続期間を通じて定期的に行われます。 （非調整とは、各CAが鍵を変更することを選択する時刻がローカルで決定され、RPKI全体で調整されないことを意味します。）さらに、秘密鍵の侵害の疑いにより鍵の変更が必要になる場合があるため、調整を想定することはできません。 RPKI内のすべてのCA間のこれらのイベントの。緊急鍵のロールオーバーでは、古い証明書が取り消され、新しい鍵を持つ新しい証明書が発行されます。 RPKIでキーのロールオーバーを実行するメカニズム（計画中または緊急時）を、同じアルゴリズムスイートを維持しながら[RFC6489]でカバーしています。
This document describes the mechanism to perform a key rollover in the RPKI due to the migration to a new signature algorithm suite. It specifies the process that CAs and Relying Parties (RPs) participating in the RPKI will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of months or years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children).
このドキュメントでは、新しい署名アルゴリズムスイートへの移行により、RPKIでキーロールオーバーを実行するメカニズムについて説明します。これは、RPKIに参加しているCAおよび依拠当事者（RP）が、新しい（そしておそらく暗号学的に強力な）アルゴリズムセットに移行するために従う必要があるプロセスを指定します。このプロセスは、数か月または数年の時間スケールで完了する予定です。したがって、緊急遷移は指定されていません。このドキュメントで定義されている移行手順は、トップダウンの移行のみをサポートします（親は子の前に移行します）。
A signature-algorithm suite encompasses both a signature algorithm (with a specified key size range) and a one-way hash algorithm. It is anticipated that the RPKI will require the adoption of updated key sizes and/or different algorithm suites over time. This document treats the adoption of a new hash algorithm while retaining the current signature algorithm as equivalent to an algorithm migration, and requires the CA to change its key. Migration to a new algorithm suite will be required in order to maintain an acceptable level of cryptographic security and protect the integrity of certificates, Certificate Revocation Lists (CRLs), and signed objects in the RPKI. All of the data structures in the RPKI explicitly identify the signature and hash algorithms being used. However, experience has demonstrated that the ability to represent algorithm IDs is not sufficient to enable migration to new algorithm suites (algorithm agility). One also must ensure that protocols, infrastructure elements, and operational procedures also accommodate the migration from one algorithm suite to another. Algorithm migration is expected to be very infrequent, and it will require the support of a "current" and "next" suite for a prolonged interval, probably several years.
署名アルゴリズムスイートには、（指定されたキーサイズ範囲を持つ）署名アルゴリズムと一方向ハッシュアルゴリズムの両方が含まれます。 RPKIでは、時間の経過とともに、更新されたキーサイズや異なるアルゴリズムスイートの採用が必要になると予想されます。このドキュメントでは、現在の署名アルゴリズムを保持しながら、新しいハッシュアルゴリズムの採用をアルゴリズムの移行と同等に扱い、CAにキーの変更を要求します。許容可能なレベルの暗号化セキュリティを維持し、証明書、証明書失効リスト（CRL）、およびRPKI内の署名付きオブジェクトの整合性を保護するには、新しいアルゴリズムスイートへの移行が必要です。 RPKIのすべてのデータ構造は、使用されている署名とハッシュアルゴリズムを明示的に識別します。ただし、アルゴリズムIDを表現する機能は、新しいアルゴリズムスイート（アルゴリズムの俊敏性）への移行を可能にするのに十分ではないことが経験から示されています。また、プロトコル、インフラストラクチャ要素、および運用手順が、あるアルゴリズムスイートから別のアルゴリズムスイートへの移行にも対応できるようにする必要もあります。アルゴリズムの移行は非常にまれであると予想され、長期間（おそらく数年）にわたって「現在の」および「次の」スイートのサポートが必要になります。
This document defines how entities in the RPKI execute a planned CA key rollover when the algorithm suite changes. The description covers actions by CAs, repository operators, and RPs. It describes the behavior required of both CAs and RPs to make such key changes work in the RPKI context, including how the RPKI repository system is used to support key rollover.
このドキュメントでは、アルゴリズムスイートが変更されたときに、RPKIのエンティティが計画されたCAキーのロールオーバーを実行する方法を定義します。説明には、CA、リポジトリオペレータ、およびRPによるアクションが含まれます。 RPKIリポジトリシステムを使用してキーのロールオーバーをサポートする方法など、RPKIコンテキストでこのようなキーの変更を機能させるためにCAとRPの両方に必要な動作について説明します。
This document does not specify any algorithm suite per se. The RPKI Certificate Policy (CP) [RFC6484] mandates the use of the algorithms defined in [RFC6485] by CAs and RPs. When an algorithm transition is initiated, [RFC6485] MUST be updated (as defined in Section 4.1 of this document) to redefine the required algorithms for compliant RPKI CAs and RPs under the CP. The CP will not change as a side effect of algorithm transition, and thus the policy OID in RPKI certificates will not change.
このドキュメントでは、アルゴリズムスイート自体は指定されていません。 RPKI証明書ポリシー（CP）[RFC6484]は、CAおよびRPによる[RFC6485]で定義されたアルゴリズムの使用を義務付けています。アルゴリズムの移行が開始されると、[RFC6485]を更新して（このドキュメントのセクション4.1で定義されているように）、CPに準拠するRPKI CAおよびRPに必要なアルゴリズムを再定義する必要があります。アルゴリズムの移行の副作用としてCPは変更されないため、RPKI証明書のポリシーOIDは変更されません。
For each algorithm transition, an additional document (the algorithm transition timetable) MUST be published (as a BCP) to define the dates for each milestone defined in this document. It will define dates for the phase transitions consistent with the descriptions provided in Section 4. It also will describe how the RPKI community will measure the readiness of CAs and RPs to transition to each phase. CAs publish certificates, CRLs, and other signed objects under the new algorithm suite as the transition progresses. This provides visibility into the deployment of the new algorithm suite, enabling the community to evaluate deployment progress. The transition procedure allows CAs to remove old certificates, CRLs, and signed products after the twilight date, which provides the ability to observe and measure the withdrawal of the old algorithm suite. Thus, the phases defined in this document enable the community to evaluate the progress of the transition. The timetable document will also describe procedures to amend the timetable if problems arise in implementing later phases of the transition. It is RECOMMENDED that the timetable document be developed by representatives of the RPKI community, e.g., IANA, Internet Registries, and network operators.
アルゴリズムの移行ごとに、このドキュメントで定義されている各マイルストーンの日付を定義するために、追加のドキュメント（アルゴリズムの移行タイムテーブル）を（BCPとして）公開する必要があります。セクション4の説明と一致するフェーズ移行の日付を定義します。また、RPKIコミュニティがCAおよびRPの各フェーズへの移行の準備状況を測定する方法についても説明します。 CAは、移行が進むにつれて、新しいアルゴリズムスイートの下で証明書、CRL、およびその他の署名済みオブジェクトを公開します。これにより、新しいアルゴリズムスイートの展開を可視化し、コミュニティが展開の進行状況を評価できるようにします。移行手順により、CAは古い証明書、CRL、および署名された製品を夕暮れ後に削除できます。これにより、古いアルゴリズムスイートの撤回を観察および測定することができます。したがって、このドキュメントで定義されているフェーズにより、コミュニティは移行の進捗状況を評価できます。タイムテーブルドキュメントには、移行の後半のフェーズの実装で問題が発生した場合にタイムテーブルを修正する手順も記載されています。タイムテーブルドキュメントは、RPANAコミュニティの代表者（IANA、インターネットレジストリ、ネットワークオペレーターなど）が作成することをお勧めします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "NOT RECOMMENDED" and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「NOT RECOMMENDED」、「OPTIONAL」このドキュメントの[RFC2119]で説明されているように解釈されます。
This document assumes that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and "A Profile for Resource Certificate Repository Structure" [RFC6481]. Additional terms and conventions used in examples are provided below.
このドキュメントは、読者が「インターネットX.509公開鍵インフラストラクチャ証明書と証明書失効リスト（CRL）プロファイル」[RFC5280]、「IPアドレスとAS識別子のX.509拡張機能」で説明されている用語と概念に精通していることを想定しています。 RFC3779]、および「リソース証明書リポジトリ構造のプロファイル」[RFC6481]。例で使用されている追加の用語と規則を以下に示します。
Algorithm migration: A planned transition from one signature and hash algorithm to a new signature and hash algorithm.
アルゴリズムの移行：1つの署名とハッシュアルゴリズムから新しい署名とハッシュアルゴリズムへの計画的な移行。
Algorithm Suite A: The "current" algorithm suite used for hashing and signing; used in examples in this document.
アルゴリズムスイートA：ハッシュと署名に使用される「現在の」アルゴリズムスイート。このドキュメントの例で使用されています。
Algorithm Suite B: The "next" algorithm suite used for hashing and signing; used in examples in this document.
アルゴリズムスイートB：ハッシュと署名に使用される「次の」アルゴリズムスイート。このドキュメントの例で使用されています。
CA X: The CA that issued CA Y's certificate (i.e., CA Y's parent); used in examples in this document.
CA X：CA Yの証明書を発行したCA（つまり、CA Yの親）。このドキュメントの例で使用されています。
CA Y: The non-leaf CA; used in examples in this document.
CA Y：非リーフCA。このドキュメントの例で使用されています。
CA Z: A CA that is a "child" of CA Y; used in examples in this document.
CA Z：CA Yの「子」であるCA。このドキュメントの例で使用されています。
Correspond: Two certificates issued under different algorithm suites correspond to one another if they are issued to the same entity by the same CA and bind identical Internet Number Resources (INRs) to that entity. Two CRLs correspond if they are issued by the same CA and enumerate corresponding certificates. Two signed objects (other than manifests) correspond if they are verified using corresponding end-entity (EE) certificates and they contain the same encapsulated Context Info field. Two manifests correspond if they encompass corresponding certificates, Route Origination Authorizations (ROAs), CRLs, and other signed objects. (The term "equivalent" is used synonymously when referring to such RPKI signed products.)
対応：異なるアルゴリズムスイートで発行された2つの証明書は、同じCAによって同じエンティティに発行され、同一のインターネット番号リソース（INR）をそのエンティティにバインドする場合、互いに対応します。 2つのCRLは、同じCAによって発行され、対応する証明書を列挙する場合に対応します。 2つの署名付きオブジェクト（マニフェスト以外）は、対応するエンドエンティティ（EE）証明書を使用して検証され、同じカプセル化されたコンテキスト情報フィールドが含まれている場合に対応します。 2つのマニフェストは、対応する証明書、Route Origination Authorizations（ROA）、CRL、およびその他の署名付きオブジェクトを含む場合に対応します。 （「同等」という用語は、そのようなRPKI署名付き製品を指す場合に同意語として使用されます。）
Leaf CA: A CA that issues only EE certificates.
リーフCA：EE証明書のみを発行するCA。
Non-Leaf CA: A CA that issues certificates to other CAs.
非リーフCA：他のCAに証明書を発行するCA。
PoP (proof of possession): Execution of a protocol that demonstrates to an issuer that a subject requesting a certificate possesses the private key corresponding to the public key in the certificate request submitted by the subject.
PoP（所有の証明）：証明書を要求するサブジェクトが、サブジェクトによって送信された証明書リクエスト内の公開キーに対応する秘密キーを所有していることを発行者に示すプロトコルの実行。
ROA: Route Origination Authorization, as defined in [RFC6482].
ROA：[RFC6482]で定義されているルート作成承認。
Signed product set (also called set or product set): A collection of certificates, signed objects, a CRL and a manifest that are associated by virtue of being verifiable under the same parent CA certificate
署名された製品セット（セットまたは製品セットとも呼ばれます）：同じ親CA証明書の下で検証可能であることによって関連付けられた証明書、署名付きオブジェクト、CRL、およびマニフェストのコレクション
The "current" RPKI algorithm suite (Suite A) is defined in the RPKI CP document, by reference to [RFC6485]. When a migration of the RPKI algorithm suite is needed, the first step MUST be an update of [RFC6485] to define the new algorithm suite. The algorithm transition timeline document MUST also be published (as a BCP) to inform the community of the dates selected for milestones in the transition process, as described in Section 4.1.
「現在の」RPKIアルゴリズムスイート（スイートA）は、[RFC6485]を参照して、RPKI CPドキュメントで定義されています。 RPKIアルゴリズムスイートの移行が必要な場合、最初のステップは、新しいアルゴリズムスイートを定義するための[RFC6485]の更新でなければなりません。セクション4.1で説明されているように、移行プロセスのマイルストーンに選択された日付をコミュニティに通知するために、アルゴリズム移行タイムラインドキュメントも（BCPとして）公開する必要があります。
CA Ready Algorithm B Date: After this date, all non-leaf CAs MUST be ready to process a request from a child CA to issue a certificate under the Algorithm Suite B. All CAs publishing an [RFC6490] Trust Anchor Locator (TAL) for Algorithm Suite A MUST also publish the correspondent TAL for Algorithm Suite B.
CA対応アルゴリズムBの日付：この日付以降、すべての非リーフCAは、アルゴリズムスイートBの下で証明書を発行するために子CAからの要求を処理する準備ができている必要があります。[RFC6490]トラストアンカーロケーター（TAL）を発行するすべてのCAアルゴリズムスイートAは、アルゴリズムスイートBの対応するTALも公開する必要があります。
CA Go Algorithm B Date: After this date, all CAs MUST have reissued all their signed product sets under Algorithm Suite B.
CA GoアルゴリズムBの日付：この日付以降、すべてのCAはアルゴリズムスイートBに基づいて、署名されたすべての製品セットを再発行する必要があります。
RP Ready Algorithm B Date: After this date, all RPs MUST be prepared to process signed material issued under Algorithm Suite B.
RP対応アルゴリズムBの日付：この日付以降、すべてのRPは、アルゴリズムスイートBに基づいて発行された署名済み資料を処理する準備を整える必要があります。
Twilight Date: After this date, a CA MAY cease issuing signed products under Algorithm Suite A. Also, after this date, an RP MAY cease to validate signed materials issued under Algorithm Suite A.
トワイライト日：この日付以降、CAはAlgorithm Suite Aに基づいて署名された製品の発行を中止する場合があります。また、この日付以降、RPはAlgorithm Suite Aに基づいて発行された署名された資料の検証を中止する場合があります。
End-Of-Life (EOL) Date: After this date, Algorithm Suite A MUST be deprecated using the process in Section 10, and all Algorithm Suite A TALs MUST be removed from their publication points.
サポート終了（EOL）日付：この日付以降、セクション10のプロセスを使用してアルゴリズムスイートAを非推奨にし、すべてのアルゴリズムスイートA TALを公開ポイントから削除する必要があります。
The migration process described in this document involves a series of steps that MUST be executed in chronological order by CAs and RPs. The only milestone at which both CAs and RPs take action at the same time is the EOL Date. Due to the decentralized nature of the RPKI infrastructure, it is expected that an algorithm transition will span several years.
このドキュメントで説明する移行プロセスには、CAとRPによって時系列で実行する必要がある一連の手順が含まれます。 CAとRPの両方が同時にアクションを実行する唯一のマイルストーンは、EOL日付です。 RPKIインフラストラクチャの分散性により、アルゴリズムの移行には数年かかると予想されます。
In order to facilitate the transition, CAs will start issuing certificates using Algorithm B in a hierarchical, top-down fashion. In our example, CA Y will issue certificates using Algorithm Suite B only after CA X has started to do so (CA Y Ready Algorithm B Date > CA X Ready Algorithm B Date). This ordered transition avoids the issuance of "mixed" suite CA certificates, e.g., a CA certificate signed using Suite A that contains a key from Suite B. In the RPKI, a CA MUST NOT sign a CA certificate carrying a subject key that corresponds to an algorithm suite that differs from the one used to sign the certificate. (X.509 accommodates such mixed algorithm certificates, but this process avoids using that capability.) A non-top-down transition approach would require the use of such mixed-mode certificates and would lead to exponential growth of the RPKI repository. Also, because the RPKI CP mandates PoP for certificate requests, it is not possible for a CA to request a certificate for Algorithm Suite B until its parent CA supports that suite. (See Section 5 for more details.)
移行を容易にするために、CAは階層的なトップダウン方式でアルゴリズムBを使用して証明書の発行を開始します。この例では、CA Yは、CA Xが開始した後にのみ、アルゴリズムスイートBを使用して証明書を発行します（CA Y準備アルゴリズムB日付> CA X準備アルゴリズムB日付）。この順序付けされた移行により、「混合」スイートCA証明書（スイートBからのキーを含むスイートAを使用して署名されたCA証明書など）の発行が回避されます。RPKIでは、CAは、証明書の署名に使用されたものとは異なるアルゴリズムスイート。 （X.509はこのような混合アルゴリズム証明書に対応しますが、このプロセスではその機能の使用を回避します。）トップダウン以外の移行アプローチでは、そのような混合モード証明書を使用する必要があり、RPKIリポジトリの指数関数的増加につながります。また、RPKI CPは証明書要求に対してPoPを要求するため、親CAがそのスイートをサポートするまで、CAがアルゴリズムスイートBの証明書を要求することはできません。 （詳細については、セクション5を参照してください。）
The algorithm agility model described here does not prohibit a CA from issuing an EE certificate with a subject public key from a different algorithm suite, if that certificate is not used to verify repository objects. This exception to the mixed algorithm suite certificate rule is allowed because an EE certificate that is not used to verify repository objects does not interfere with the ability of RPs to download and verify repository content. As noted above, every CA in the RPKI is required to perform a PoP check for the subject public key when issuing a certificate. In general, a subject cannot assume that a CA is capable of supporting a different algorithm. However, if the subject is closely affiliated with the CA, it is reasonable to assume that there are ways for the subject to know whether the CA can support a request to issue an EE certificate containing a specific, different public key algorithm. This document does not specify how a subject can determine whether a CA is capable of issuing a mixed suite EE certificate, because it anticipates that such certificates will be issued only in contexts where the subject and CA are sufficiently closely affiliated (for example, an ISP issuing certificates to devices that it manages).
ここで説明するアルゴリズムの俊敏性モデルは、証明書がリポジトリオブジェクトの検証に使用されない場合、CAが別のアルゴリズムスイートからのサブジェクト公開鍵を使用してEE証明書を発行することを禁止しません。リポジトリー・オブジェクトの検証に使用されないEE証明書は、RPがリポジトリーのコンテンツをダウンロードして検証する機能に干渉しないため、混合アルゴリズム・スイートの証明書ルールに対するこの例外は許可されます。上記のように、RPKIのすべてのCAは、証明書を発行するときにサブジェクトの公開鍵のPoPチェックを実行する必要があります。一般に、サブジェクトはCAが異なるアルゴリズムをサポートできると想定することはできません。ただし、サブジェクトがCAと密接に関連している場合、CAが特定の異なる公開鍵アルゴリズムを含むEE証明書を発行する要求をサポートできるかどうかをサブジェクトが知る方法があると想定するのは妥当です。このドキュメントは、CAが混合スイートEE証明書を発行できるかどうかをサブジェクトがどのように判断できるかを指定していません。そのような証明書は、サブジェクトとCAが十分に密接に関連しているコンテキスト（たとえば、ISP）でのみ発行されると予想されるためです。管理するデバイスへの証明書の発行）。
The following figure gives an overview of the process:
次の図は、プロセスの概要を示しています。
Process for RPKI CAs:
RPKI CAのプロセス：
Phase 0 Phase 1 Phase 2 Phase 4 Phase 0
--x--------x---------x-------------------x--------x---------
^ ^ ^ ^ ^
| | | | |
(1) (2) (3) (5) (6)
Process for RPKI RPs:
RPKI RPのプロセス：
Phase 0 Phase 3 Phase 4 Phase 0
-------------------------------x---------x--------x---------
^ ^ ^ ^
| | | |
(1) (4) (5) (6)
(1) RPKI algorithm document is updated, and the algorithm transition timeline document is issued (2) CA Ready Algorithm B Date (3) CA Go Algorithm B Date (4) RP Ready Algorithm B Date (5) Twilight Date (6) End-Of-Life (EOL) Date
（1）RPKIアルゴリズムドキュメントが更新され、アルゴリズム移行タイムラインドキュメントが発行されます（2）CAレディアルゴリズムB日付（3）CA GoアルゴリズムB日付（4）RPレディアルゴリズムB日付（5）トワイライト日付（6）終了-寿命（EOL）日付
Each of these milestones is discussed in the next section when each phase of the transition process is described.
これらの各マイルストーンについては、移行プロセスの各フェーズについて説明する次のセクションで説明します。
Two situations have been identified that motivate pausing or rolling back the transition process. The first situation arises if the RPKI community is not ready to make the transition. For example, many CAs might not be prepared to issue signed products under Suite B, or many RPs might not be ready to process Suite B products. Under these circumstances, the timetable MUST be reissued, postponing the date for the phase in question and pushing back the dates for later phases. The other situation arises if, during the transition, serious concerns arise about the security of the Suite B algorithms. Such concerns would motivate terminating the transition and rolling back signed products, i.e., reverting to Suite A. In this case, the timetable MUST be republished, and the RPKI algorithm document MUST be superseded. The phase descriptions below allude to these two situations, as appropriate.
移行プロセスを一時停止またはロールバックする2つの状況が確認されています。最初の状況は、RPKIコミュニティが移行を行う準備ができていない場合に発生します。たとえば、多くのCAはSuite Bで署名付きの製品を発行する準備ができていない場合や、多くのRPがSuite B製品を処理する準備ができていない場合があります。これらの状況下では、タイムテーブルを再発行して、問題のフェーズの日付を延期し、後のフェーズの日付を差し戻す必要があります。他の状況は、移行中にSuite Bアルゴリズムのセキュリティについて深刻な懸念が生じた場合に発生します。このような懸念は、移行の終了と署名済み製品のロールバック、つまりSuite Aへの復帰の動機となります。この場合、タイムテーブルを再発行する必要があり、RPKIアルゴリズムドキュメントを置き換える必要があります。以下のフェーズの説明は、必要に応じてこれら2つの状況をほのめかしています。
Phase 0 is the steady-state phase of the process; throughout this phase, Algorithm Suite A is the only supported algorithm suite in the RPKI. Phase 0 is also the steady state for the RPKI.
フェーズ0は、プロセスの定常状態フェーズです。このフェーズ全体を通じて、アルゴリズムスイートAは、RPKIでサポートされている唯一のアルゴリズムスイートです。フェーズ0もRPKIの定常状態です。
During Phase 0, CAs X, Y, and Z are required to generate signed product sets using only Algorithm Suite A. Also, RPs are required to validate signed product sets issued using only Algorithm Suite A.
フェーズ0では、CA X、Y、およびZは、Algorithm Suite Aのみを使用して署名された製品セットを生成する必要があります。また、RPは、Algorithm Suite Aのみを使用して発行された署名済み製品セットを検証する必要があります。
The following figure shows an example of the structure of signed objects in the repository, indicating the algorithm suites in use and showing the relationships between three CAs (X, Y, and Z) that form a certification chain. Vertical alignment in the figure indicates objects signed by the same CA using the same private key. The differences in horizontal indentation also represent the use of different publication points for objects signed by different CAs. The characters "|->" are used for visualization purposes for both the signing relationship and the publication point change. For example, the objects CA-Y-Certificate-Algorithm-Suite-A, CA-X-CRL-Algorithm-Suite-A, and CA-X-Signed-Objects-Algorithm-Suite-A are all signed using the private key corresponding to CA-X-Certificate-Algorithm-Suite-A and published at CA X's corresponding publication point.
次の図は、リポジトリ内の署名付きオブジェクトの構造の例を示し、使用中のアルゴリズムスイートを示し、証明書チェーンを形成する3つのCA（X、Y、およびZ）間の関係を示しています。図の垂直方向の配置は、同じ秘密鍵を使用して同じCAによって署名されたオブジェクトを示しています。水平インデントの違いは、異なるCAによって署名されたオブジェクトの異なる公開ポイントの使用も表しています。文字「|->」は、署名関係と公開ポイントの変更の両方を視覚化する目的で使用されます。たとえば、オブジェクトCA-Y-Certificate-Algorithm-Suite-A、CA-X-CRL-Algorithm-Suite-A、およびCA-X-Signed-Objects-Algorithm-Suite-Aはすべて、秘密鍵を使用して署名されています。 CA-X-Certificate-Algorithm-Suite-Aに対応し、CA Xの対応する公開ポイントで公開されます。
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
Note: Cert-XA represents the certificate for CA X, which is signed using Algorithm Suite A.
注：Cert-XAは、アルゴリズムスイートAを使用して署名されたCA Xの証明書を表します。
The first milestone initiates the migration process. It updates [RFC6485] with the following definitions for the RPKI:
最初のマイルストーンが移行プロセスを開始します。 [RFC6485]を次のRPKIの定義で更新します。
o Algorithm Suite A
o アルゴリズムスイートA
o Algorithm Suite B Additionally, the new algorithm transition timeline document MUST be published with the following information:
oアルゴリズムスイートBさらに、新しいアルゴリズム移行タイムラインドキュメントを次の情報とともに公開する必要があります。
o CA Ready Algorithm B Date
o CA対応アルゴリズムBの日付
o CA Go Algorithm B Date
o CA GoアルゴリズムBの日付
o RP Ready Algorithm B Date
o RPレディアルゴリズムB日付
o Twilight Date
o ミステリー日
o EOL Date
o EOLの日付
o Readiness metrics for CAs and RPs in each phase
o 各フェーズのCAおよびRPの準備指標
Each date specified here is assumed to be at one minute after midnight, UTC. No finer granularity time specification is required or supported.
ここで指定された各日付は、UTCの午前0時の1分を想定しています。より細かい粒度の時間指定は不要であり、サポートされていません。
Phase 1 starts at the CA Ready Algorithm B Date. During Phase 1, all non-leaf CAs MUST be ready to process a request from a child CA to issue or revoke a certificate using Algorithm Suite B. If it is determined that a substantial number of CAs are not ready, the algorithm transition timeline document MUST be reissued, as noted in Section 4.2. However, CAs that are capable of issuing Suite B certificates may continue to do so, if requested by their child CAs. As this phase does not require any RPs to process signed objects under Suite B, and since Suite B product sets SHOULD be stored at independent publication points, there is no adverse impact on RPs. If the Suite B algorithm is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced, and Algorithm Suite B MUST be deprecated using the process described in Section 10.
フェーズ1は、CA Ready Algorithm Bの日付から始まります。フェーズ1の間、すべての非リーフCAは、アルゴリズムスイートBを使用して証明書を発行または失効させるために、子CAからの要求を処理する準備ができている必要があります。かなりの数のCAが準備できていないと判断された場合、アルゴリズム移行タイムラインドキュメントセクション4.2に記載されているように、再発行する必要があります。ただし、スイートB証明書を発行できるCAは、子CAから要求された場合、引き続き発行できます。このフェーズでは、スイートBで署名されたオブジェクトを処理するためにRPを必要とせず、スイートB製品セットは独立した公開ポイントに格納する必要があるため、RPに悪影響はありません。 Suite Bアルゴリズムが不適切であると判断された場合は、アルゴリズム移行のタイムラインとアルゴリズム仕様文書を置き換える必要があり、アルゴリズムSuite Bはセクション10で説明されているプロセスを使用して非推奨にする必要があります。
Because the transition will happen using a hierarchical, top-down model, a child CA will be able to issue certificates using Algorithm Suite B only after its parent CA has issued its own. The RPKI provisioning protocol can identify if a parent CA is capable of issuing certificates using Algorithm Suite B and can identify the corresponding algorithm suite in each Certificate Signing Request (CSR; see Section 5). During much of this phase, the Suite B product tree will be incomplete, i.e., not all CAs will have issued products under Suite B. Thus, for production purposes, RPs MUST fetch and validate only Suite A products. Suite B products should be fetched and processed only for testing purposes.
移行は階層的なトップダウンモデルを使用して行われるため、子CAは、その親CAが独自に発行した後でのみ、アルゴリズムスイートBを使用して証明書を発行できます。 RPKIプロビジョニングプロトコルは、親CAがアルゴリズムスイートBを使用して証明書を発行できるかどうかを識別し、各証明書署名要求（CSR、セクション5を参照）で対応するアルゴリズムスイートを識別できます。このフェーズの大部分の間、スイートBの製品ツリーは不完全になります。つまり、すべてのCAがスイートBの下で製品を発行するわけではありません。したがって、本番環境では、RPはスイートA製品のみをフェッチして検証する必要があります。スイートB製品は、テスト目的でのみ取得および処理する必要があります。
The following figure shows the status of repository entries for the three example CAs during this phase. Two distinct certificate chains are maintained, and CA Z has not yet requested any material using Algorithm Suite B.
次の図は、このフェーズでの3つのサンプルCAのリポジトリエントリのステータスを示しています。 2つの別個の証明書チェーンが維持されており、CA ZはAlgorithm Suite Bを使用した資料をまだ要求していません。
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
Phase 2 starts at the CA Go Algorithm B Date. At the start of this phase, each signed product set MUST be available using both Algorithm Suite A and Algorithm Suite B. Thus, prior to the start of this phase, every CA MUST ensure that there is a Suite B product corresponding to each Suite A product that the CA has issued. Throughout this phase, each CA MUST maintain this correspondence. During this phase, RPs MUST be prepared to validate sets issued using Algorithm Suite A and MAY be prepared to validate sets issued using the Algorithm Suite B.
フェーズ2はCA GoアルゴリズムBの日付から始まります。このフェーズの開始時に、各署名済み製品セットは、アルゴリズムスイートAとアルゴリズムスイートBの両方を使用して利用できる必要があります。したがって、このフェーズの開始前に、すべてのCAは、各スイートAに対応するスイートB製品があることを確認する必要があります。 CAが発行した製品。このフェーズ全体を通じて、各CAはこの対応を維持する必要があります。このフェーズでは、RPは、アルゴリズムスイートAを使用して発行されたセットを検証するために準備する必要があり、アルゴリズムスイートBを使用して発行したセットを検証するために準備する必要があります。
If it is determined that a substantial number of CAs are not ready, the algorithm transition timeline document MUST be reissued, as noted in Section 4.2. (Since the processing requirement for RPs here is a MAY, if RPs have problems with Suite B products, this does not require pushing back the Phase 2 milestone, but it does motivate delaying the start of Phase 3.) CAs that are capable of publishing products under Suite B MAY continue to do so. Phase 2, like Phase 1, does not require any RPs to process signed objects under Suite B. Also, Suite B products SHOULD be stored at independent publication points so that there is no adverse impact on RPs that are not prepared to process Suite B products. (See Section 9 for additional details.) If the Suite B algorithm is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced, and Algorithm Suite B MUST be deprecated using the process described in Section 10.
相当数のCAの準備ができていないと判断された場合は、セクション4.2に記載されているように、アルゴリズム移行タイムラインドキュメントを再発行する必要があります。 （ここでのRPの処理要件はMAYであるため、RPにSuite B製品に問題がある場合、フェーズ2マイルストーンをプッシュバックする必要はありませんが、フェーズ3の開始を遅らせる動機付けになります。）発行可能なCA Suite Bの製品は引き続き使用できます。フェーズ2は、フェーズ1と同様に、スイートBの下で署名されたオブジェクトを処理するためにRPを必要としません。また、スイートB製品は、スイートB製品を処理する準備のないRPに悪影響を及ぼさないように、独立した公開ポイントに保存する必要があります。 。 （詳細については、セクション9を参照してください。）Suite Bアルゴリズムが不適切であると判断された場合、アルゴリズム移行のタイムラインとアルゴリズム仕様文書を置き換えなければならず、セクション10で説明されているプロセスを使用して、アルゴリズムスイートBを非推奨にする必要があります。
It is RECOMMENDED that RPs that can process Algorithm Suite B fetch and validate Suite B products. RPs that are not ready to process Suite B products MUST continue to make use of Suite A products. An RP that elects to validate signed product sets using both Algorithm Suite A and Algorithm Suite B should expect the same results. If there are discrepancies when evaluating corresponding signed product sets, successful validation of either product set is acceptable. A detailed analysis of the validation of multiple instances of signed objects is included in Section 6.
Algorithm Suite Bを処理できるRPがSuite B製品をフェッチして検証することをお勧めします。スイートB製品を処理する準備ができていないRPは、スイートA製品を引き続き使用する必要があります。 Algorithm Suite AとAlgorithm Suite Bの両方を使用して署名済み製品セットを検証することを選択したRPは、同じ結果を期待する必要があります。対応する署名済み製品セットを評価するときに矛盾がある場合は、どちらかの製品セットの検証が成功しても問題ありません。署名されたオブジェクトの複数のインスタンスの検証の詳細な分析は、セクション6に含まれています。
The following figure shows the status of the repository entries for the three example CAs throughout this phase, where all signed objects are available using both algorithm suites.
次の図は、このフェーズ全体にわたる3つのCAの例のリポジトリエントリのステータスを示しています。すべての署名付きオブジェクトは、両方のアルゴリズムスイートを使用して利用できます。
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
|-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
Phase 3 starts at the RP Ready Algorithm B Date. During this phase, all signed product sets are available using both algorithm suites, and all RPs MUST be able to validate them. (The correspondence between Suite A and Suite B products was required for Phase 2 and was maintained throughout that phase. The same requirements apply throughout this phase.) It is RECOMMENDED that, in preparation for Phase 4, RPs retrieve and process Suite B product sets first and treat them as the preferred product sets for validation throughout this phase. Thus, an RP SHOULD try to validate the sets of signed products retrieved from the Algorithm Suite B repository first.
フェーズ3は、RP作動可能アルゴリズムBの日付から始まります。このフェーズでは、両方のアルゴリズムスイートを使用してすべての署名付き製品セットを利用でき、すべてのRPがそれらを検証できる必要があります。 （スイートAとスイートBの製品間の通信はフェーズ2で必要であり、そのフェーズ全体で維持されました。このフェーズ全体で同じ要件が適用されます。）フェーズ4の準備として、RPがスイートB製品セットを取得して処理することをお勧めします。まず、それらをこのフェーズ全体での検証に適した製品セットとして扱います。したがって、RPは最初にAlgorithm Suite Bリポジトリから取得された署名済み製品のセットを検証する必要があります。
If a substantial number of RPs are unable to process product sets signed with Suite B, the algorithm transition timeline document MUST be reissued, pushing back the date for this and later milestones, as discussed in Section 4.2. Since the Suite B products SHOULD be published at distinct publication points, RPs that cannot process Suite B products can be expected to revert to the Suite A products that still exist. If the Suite B algorithm is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced and Algorithm Suite B MUST be deprecated using the process described in Section 10.
相当数のRPがSuite Bで署名された製品セットを処理できない場合、セクション4.2で説明されているように、アルゴリズム移行タイムラインドキュメントを再発行して、これ以降のマイルストーンの日付を押し戻す必要があります。スイートB製品は別個の公開ポイントで公開する必要があるため（SHOULD）、スイートB製品を処理できないRPは、まだ存在するスイートA製品に戻ることが期待できます。 Suite Bアルゴリズムが不適切であると判断された場合は、アルゴリズム移行のタイムラインとアルゴリズム仕様ドキュメントを置き換え、セクション10で説明されているプロセスを使用してAlgorithm Suite Bを非推奨にする必要があります。
There are no changes to the CA behavior throughout this phase.
このフェーズを通じて、CAの動作に変更はありません。
Phase 4 starts at the Twilight Date. At that date, Algorithm A is labeled as "old" and the Algorithm B is labeled as "current".
フェーズ4はトワイライト日から始まります。その日、アルゴリズムAは「古い」というラベルが付けられ、アルゴリズムBは「現在の」というラベルが付けられます。
During this phase, all signed product sets MUST be issued using Algorithm Suite B and MAY be issued using Algorithm Suite A. All signed products sets issued using Suite B MUST be published at their corresponding publication points. Signed products sets issued using Suite A might not be available at their corresponding publication points. Every RP MUST validate signed product sets using Suite B. RPs MAY validate signed product sets using Suite A. However, RPs SHOULD NOT assume that the collection of Suite A product sets is complete. Thus, RPs SHOULD make use of only Suite B products sets. (See Section 6 for further details.)
このフェーズでは、すべての署名付き製品セットはアルゴリズムスイートBを使用して発行する必要があり、アルゴリズムスイートAを使用して発行できます。スイートBを使用して発行したすべての署名済み製品セットは、対応する公開ポイントで公開する必要があります。 Suite Aを使用して発行された署名付き製品セットは、対応する公開ポイントでは入手できない場合があります。すべてのRPは、スイートBを使用して署名済み製品セットを検証する必要があります。RPは、スイートAを使用して署名済み製品セットを検証できます（MAY）。ただし、RPは、スイートA製品セットの収集が完了しているとは想定しないでください。したがって、RPはスイートB製品セットのみを使用する必要があります（SHOULD）。 （詳細については、セクション6を参照してください。）
If it is determined that many RPs are not capable of processing the new algorithm suite, the algorithm transition timeline document MUST be reissued, pushing back the date for this and the next milestone. The document MUST require the CA not to remove Suite A product sets if this phase is delayed. If Algorithm Suite B is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced, Algorithm Suite B MUST be deprecated using the process described in Section 10, and CAs MUST NOT remove Suite A product sets. At this stage, RPs are still capable of processing Suite A signed products, so the RPKI is still viable.
多くのRPが新しいアルゴリズムスイートを処理できないと判断された場合、アルゴリズム移行タイムラインドキュメントを再発行して、この日付と次のマイルストーンの日付を押し戻す必要があります。このフェーズが遅延する場合、ドキュメントはCAにSuite A製品セットを削除しないように要求する必要があります。アルゴリズムスイートBが不適切であると見なされた場合、アルゴリズム移行のタイムラインとアルゴリズム仕様文書を置き換える必要があります。アルゴリズムスイートBは、セクション10で説明されているプロセスを使用して非推奨にし、CAはスイートA製品セットを削除してはなりません。この段階では、RPはSuite Aの署名付き製品を処理できるため、RPKIはまだ実行可能です。
The following figure describes a possible status for the repositories of the example CAs.
次の図は、サンプルCAのリポジトリの考えられるステータスを示しています。
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZB)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
The EOL Date triggers the return to Phase 0 (steady state). At this point, the old algorithm suite, Algorithm Suite A, MUST be deprecated using the process described in Section 10.
EOL日付により、フェーズ0（定常状態）に戻ります。この時点で、古いアルゴリズムスイートであるアルゴリズムスイートAは、セクション10で説明されているプロセスを使用して非推奨にする必要があります。
This phase closes the loop, as the new algorithm suite (Algorithm Suite B) is now the only required algorithm suite in RPKI. From this point forward, this suite is referred to as Algorithm Suite A.
新しいアルゴリズムスイート（アルゴリズムスイートB）がRPKIで唯一必要なアルゴリズムスイートであるため、このフェーズはループを閉じます。これ以降、このスイートはアルゴリズムスイートAと呼ばれます。
If it is determined that many RPs are not capable of processing the new algorithm suite, the algorithm transition timeline document MUST be reissued, pushing back the date for this milestone.
多くのRPが新しいアルゴリズムスイートを処理できないと判断された場合は、アルゴリズム移行タイムラインドキュメントを再発行して、このマイルストーンの日付を押し戻す必要があります。
The migration described in this document is a top-down process where two synchronization issues need to be solved between child and parent CAs:
このドキュメントで説明する移行はトップダウンプロセスであり、子CAと親CAの間で2つの同期の問題を解決する必要があります。
o A child CA needs to identify which algorithm suites are supported by its parent CA.
o 子CAは、親CAによってサポートされているアルゴリズムスイートを識別する必要があります。
o A child CA needs to signal which algorithm suite should be used by its parent CA to sign a CSR.
o 子CAは、CSRに署名するために親CAが使用するアルゴリズムスイートを通知する必要があります。
The RPKI provisioning protocol [RFC6492] supports multiple algorithms suites by implementing different resource classes for each suite. Several different resource classes also may use the same algorithm suite for different resource sets.
RPKIプロビジョニングプロトコル[RFC6492]は、スイートごとに異なるリソースクラスを実装することにより、複数のアルゴリズムスイートをサポートしています。いくつかの異なるリソースクラスも、異なるリソースセットに対して同じアルゴリズムスイートを使用する場合があります。
A child CA that wants to identify which algorithm suites are supported by its parent CA MUST perform the following tasks:
親CAでサポートされているアルゴリズムスイートを特定する子CAは、次のタスクを実行する必要があります。
1. Establish a provisioning protocol session with its parent CA.
1. 親CAとのプロビジョニングプロトコルセッションを確立します。
2. Perform a "list" command as described in Section 3.3.1 of [RFC6492].
2. [RFC6492]のセクション3.3.1に記載されている「list」コマンドを実行します。
3. From the Payload in the "list response" resource class, extract the "issuer's certificate" for each class. The algorithm suite for each class will match the algorithm suite used to issue the corresponding "issuer's certificate" (as specified in the SubjectPublicKeyInfo field of that certificate).
3. 「リスト応答」リソースクラスのペイロードから、各クラスの「発行者の証明書」を抽出します。各クラスのアルゴリズムスイートは、対応する「発行者の証明書」を発行するために使用されるアルゴリズムスイートと一致します（その証明書のSubjectPublicKeyInfoフィールドで指定）。
A child CA that wants to specify an algorithm suite to its parent CA (e.g., in a certificate request) MUST perform the following tasks:
アルゴリズムスイートをその親CAに指定したい（たとえば、証明書リクエストで）子CAは、次のタスクを実行する必要があります。
1. Perform the tasks described above to identify the algorithm suites supported by its parent CA and the resource class corresponding to each suite.
1. 上記のタスクを実行して、親CAでサポートされているアルゴリズムスイートと、各スイートに対応するリソースクラスを特定します。
2. Identify the corresponding resource class in the appropriate provisioning protocol command (e.g., "issue" or "revoke").
2. 適切なプロビジョニングプロトコルコマンドで対応するリソースクラスを特定します（「発行」または「取り消し」など）。
Upon receipt of a certificate request from a child CA, a parent CA will verify the PoP of the private key. If a child CA requests the issuing of a certificate using an algorithm suite that does not match a resource class, the PoP validation will fail and the request will not be performed.
子CAからの証明書要求を受信すると、親CAは秘密鍵のPoPを検証します。子CAが、リソースクラスと一致しないアルゴリズムスイートを使用して証明書の発行を要求した場合、PoP検証は失敗し、要求は実行されません。
During Phases 1, 2, 3, and 4, two algorithm suites will be valid simultaneously in RPKI. In this section, we describe the RP behavior when validating corresponding signed products using different algorithm suites.
フェーズ1、2、3、および4の間、2つのアルゴリズムスイートがRPKIで同時に有効になります。このセクションでは、さまざまなアルゴリズムスイートを使用して対応する署名済み製品を検証するときのRPの動作について説明します。
During Phase 1, two corresponding instances MAY be available for each signed product, one signed under Algorithm Suite A and one under Algorithm Suite B. As noted in Section 4.4, in this phase there is a preference for Suite A product sets. All products are available under Suite A, while only some products may be available under Suite B. For production purposes, an RP MAY fetch and validate only Suite A products. Suite B products SHOULD be fetched and validated only for test purposes. When product sets exist under both suites, they should yield equivalent results, to facilitate testing. (It is not possible to directly compare Suite A and Suite B product sets, because certificates, CRLs, and manifests will appear syntactically different. However, the output of the process, i.e., the ROA payloads -- Autonomous System number and address prefix data -- SHOULD match, modulo timing issues.)
フェーズ1では、2つの対応するインスタンスが各署名済み製品で利用可能になる場合があります。1つはAlgorithm Suite Aで署名され、もう1つはAlgorithm Suite Bで署名されます。セクション4.4で述べたように、このフェーズではSuite A製品セットが優先されます。スイートAではすべての製品を利用できますが、スイートBでは一部の製品しか利用できない場合があります。本番環境では、RPがスイートA製品のみをフェッチして検証する場合があります。スイートB製品は、テスト目的でのみフェッチおよび検証する必要があります。製品セットが両方のスイートに存在する場合、テストを容易にするために同等の結果が得られるはずです。 （スイートAとスイートBの製品セットを直接比較することはできません。これは、証明書、CRL、およびマニフェストが構文的に異なるためです。ただし、プロセスの出力、つまりROAペイロード-自律システム番号とアドレスプレフィックスデータ-一致する必要があります、モジュロタイミングの問題。）
During Phases 2 and 3 of this process, two corresponding instances of all signed products MUST be available to RPs. As noted in Section 4.5, it is RECOMMENDED that Suite B capable RPs fetch and validate Suite B products sets during Phase 2. If an RP encounters validation problems with the Suite B products, it SHOULD revert to using Suite A products. RPs that are Suite B capable MAY fetch both product sets and compare the results (e.g., ROA outputs) for testing.
このプロセスのフェーズ2および3の間、RPはすべての署名済み製品の2つの対応するインスタンスを使用できる必要があります。セクション4.5で述べたように、スイートB対応のRPがフェーズ2中にスイートB製品セットをフェッチおよび検証することをお勧めします。RPがスイートB製品で検証の問題に遭遇した場合、スイートA製品の使用に戻る必要があります。 Suite B対応のRPは、両方の製品セットをフェッチして、テストのために結果（ROA出力など）を比較できます（MAY）。
In Phase 3, all RPs MUST be Suite B capable and MUST fetch Suite B product sets. If an RP encounters problems with Suite B product sets, it can revert to Suite A products. RPs encountering such problems SHOULD contact the relevant repository maintainers (e.g., using the mechanism defined in [RFC6493] to report problems.)
フェーズ3では、すべてのRPがスイートB対応であり、スイートB製品セットをフェッチする必要があります。 RPがSuite B製品セットで問題を検出した場合、RPはSuite A製品に戻ることができます。このような問題が発生したRPは、関連するリポジトリのメンテナに連絡する必要があります（たとえば、[RFC6493]で定義されたメカニズムを使用して問題を報告します）。
During Phase 4, only Suite B product sets are required to be present for all RPKI entities, as per Section 4.7. Thus, RPs SHOULD retrieve and validate only these product sets. Retrieval of Suite A products sets may yield an incomplete set of signed products and is NOT RECOMMENDED.
フェーズ4では、セクション4.7に従って、すべてのRPKIエンティティにSuite B製品セットのみが存在する必要があります。したがって、RPはこれらの製品セットのみを取得して検証する必要があります（SHOULD）。 Suite A製品セットを取得すると、署名された製品のセットが不完全になる可能性があるため、お勧めしません。
The algorithm migration process mandates the maintenance of two parallel but equivalent certification hierarchies during Phases 2 and 3 of the process. During these phases, a CA MUST revoke and request revocation of certificates consistently under both algorithm suites. When not performing a key rollover operation (as described in Section 8), a CA requesting the revocation of its certificate during these two phases MUST perform that request for both algorithm suites (A and B). A non-leaf CA SHOULD NOT verify that its child CAs comply with this requirement. Note that a CA MUST request revocation of its certificate relative to a specific algorithm suite using the mechanism described in Section 5
アルゴリズムの移行プロセスでは、プロセスのフェーズ2とフェーズ3で、2つの並行するが同等の認証階層の維持を義務付けています。これらのフェーズの間、CAは両方のアルゴリズムスイートで一貫して証明書の取り消しと取り消しを要求する必要があります。 （セクション8で説明されているように）キーのロールオーバー操作を実行しない場合、これらの2つのフェーズ中に証明書の失効を要求するCAは、両方のアルゴリズムスイート（AおよびB）に対してその要求を実行する必要があります。非リーフCAは、その子CAがこの要件に準拠していることを確認しないでください。 CAは、セクション5で説明されているメカニズムを使用して、特定のアルゴリズムスイートに関連する証明書の失効を要求する必要があることに注意してください。
During Phase 1, a CA that revokes a certificate under Suite A SHOULD revoke the corresponding certificate under Suite B if that certificate exists. During Phase 4, a CA that revokes a certificate under Suite B SHOULD revoke the corresponding certificate under Suite A if that certificate exists.
フェーズ1の間に、スイートAで証明書を取り消すCAは、その証明書が存在する場合、スイートBで対応する証明書を取り消す必要があります（SHOULD）。フェーズ4の間に、スイートBで証明書を取り消すCAは、その証明書が存在する場合、スイートAで対応する証明書を取り消す必要があります（SHOULD）。
During Phase 1, a CA may revoke certificates under Suite B without revoking them under Suite A, since the Suite B products are for test purposes. During Phase 4, a CA may revoke certificates issued under Suite A without revoking them under Suite B, since Suite A products are being deprecated.
フェーズ1では、スイートB製品はテスト用であるため、CAはスイートAで証明書を取り消すことなく証明書を取り消す場合があります。フェーズ4の間に、スイートA製品は廃止されているため、CAはスイートAで発行された証明書をスイートBで失効せずに失効させることができます。
Key rollover (without algorithm changes) is effected independently for each algorithm suite and MUST follow the process described in [RFC6489].
キーのロールオーバー（アルゴリズムの変更なし）は、アルゴリズムスイートごとに個別に実行され、[RFC6489]で説明されているプロセスに従う必要があります。
The two parallel hierarchies that will exist during the transition process SHOULD have independent publications points. The repository structures for each algorithm suite are described in [RFC6481].
移行プロセス中に存在する2つの並列階層には、独立した公開ポイントが必要です（SHOULD）。各アルゴリズムスイートのリポジトリ構造は、[RFC6481]で説明されています。
To deprecate an algorithm suite, the following process MUST be executed by every CA in the RPKI:
アルゴリズムスイートを廃止するには、次のプロセスをRPKIのすべてのCAが実行する必要があります。
1. Each CA MUST cease issuing certificates under the suite. This means that any request for a CA certificate from a child will be rejected, e.g., sending an "error_response" message with error code "request - no such resource class", as defined in [RFC6492].
1. 各CAは、スイートの下での証明書の発行を中止する必要があります。これは、[RFC6492]で定義されているように、エラーコード "request-no such resource class"を含む "error_response"メッセージを送信するなど、子からのCA証明書の要求はすべて拒否されることを意味します。
2. Each CA MUST cease generating signed products, except the CRL and manifest, under the deprecated algorithm suite.
2. 各CAは、非推奨のアルゴリズムスイートの下で、CRLとマニフェストを除いて、署名された製品の生成を中止する必要があります。
3. Each CA MUST revoke the EE certificates for all signed products that it has issued under the deprecated algorithm suite. The CA SHOULD delete these products from its publication point to avoid burdening RPs with the need to download and process these products.
3. 各CAは、非推奨のアルゴリズムスイートで発行したすべての署名付き製品のEE証明書を取り消す必要があります。 CAは、これらの製品をダウンロードして処理する必要があるRPの負担を避けるために、これらの製品を公開ポイントから削除する必要があります（SHOULD）。
4. Each CA MUST revoke all CA certificates that it has issued under the deprecated algorithm suite.
4. 各CAは、非推奨のアルゴリズムスイートの下で発行したすべてのCA証明書を取り消す必要があります。
5. Each CA SHOULD remove all CA certificates that it has issued under the deprecated algorithm suite.
5. 各CAは、非推奨のアルゴリズムスイートで発行したすべてのCA証明書を削除する必要があります（SHOULD）。
6. Each CA that publishes a TAL under the deprecated algorithm suite MUST removed it from the TAL's publication point.
6. 非推奨のアルゴリズムスイートでTALを公開する各CAは、TALの公開ポイントからそれを削除する必要があります。
7. Each CA SHOULD continue to maintain the publication point for the deprecated algorithm suite at least until the CRL nextUpdate. This publication point MUST contain only the CRL and a manifest for that publication point. This behavior provides a window in which RPs may be able to become aware of the revoked status of the signed products that have been deleted.
7. 各CAは、少なくともCRLのnextUpdateまで、非推奨のアルゴリズムスイートの公開ポイントを維持する必要があります（SHOULD）。この公開ポイントには、CRLとその公開ポイントのマニフェストのみが含まれている必要があります。この動作は、RPが削除された署名済み製品の失効ステータスを認識できるウィンドウを提供します。
8. Each RP MUST remove any TALs that is has published under the deprecated algorithm suite.
8. 各RPは、非推奨のアルゴリズムスイートで公開されているTALを削除する必要があります。
CAs in the RPKI hierarchy may become aware of the deprecation of the algorithm suite at different times and may execute the procedure above asynchronously relative to one another. Thus, for example, a CA may request revocation of its CA certificate, only to learn that the certificate has already been revoked by the issuing CA. The revocation of a CA certificate makes the CRL and manifest issued under it incapable of validation. The asynchronous execution of this procedure likely will result in transient "inconsistencies" among the publication points associated with the deprecated algorithm suite. However, these inconsistencies should yield "fail-safe" results, i.e., the objects signed under the deprecated suite should be rejected by RPs.
RPKI階層内のCAは、異なるタイミングでアルゴリズムスイートの廃止を認識し、上記の手順を互いに非同期で実行する場合があります。したがって、たとえば、CAはCA証明書の失効を要求する場合がありますが、証明書が発行元のCAによってすでに失効されていることを知るだけです。 CA証明書の失効により、CRLとその下で発行されたマニフェストは検証できなくなります。このプロシージャの非同期実行により、非推奨のアルゴリズムスイートに関連付けられた公開ポイント間で一時的な「不整合」が発生する可能性があります。ただし、これらの不整合は「フェイルセーフ」の結果をもたらすはずです。つまり、非推奨のスイートで署名されたオブジェクトはRPによって拒否されます。
An algorithm transition in RPKI should be a very infrequent event, and it requires wide community consensus. The events that may lead to an algorithm transition may be related to a weakness of the cryptographic strength of the algorithm suite in use by RPKI, which is normal to happen over time. The procedures described in this document mean that it will take years to complete an algorithm transition. During that time, the RPKI system will be vulnerable to any cryptographic weakness that may have triggered this procedure (e.g., a downgrade attack).
RPKIのアルゴリズムの移行は非常にまれなイベントであり、幅広いコミュニティの合意が必要です。アルゴリズムの移行につながる可能性のあるイベントは、RPKIで使用されているアルゴリズムスイートの暗号強度の弱さに関連している可能性があります。このドキュメントで説明されている手順は、アルゴリズムの移行が完了するまでに数年かかることを意味しています。その間、RPKIシステムは、この手順（ダウングレード攻撃など）をトリガーした可能性のある暗号の脆弱性に対して脆弱です。
This document does not describe an emergency mechanism for algorithm migration. Due to the distributed nature of RPKI and the very large number of CAs and RPs, the authors do not believe it is feasible to effect an emergency algorithm migration procedure.
このドキュメントでは、アルゴリズム移行の緊急メカニズムについては説明していません。 RPKIの分散された性質と非常に多数のCAおよびRPのため、著者は緊急アルゴリズムの移行手順を実行することが実行可能であるとは考えていません。
If a CA does not complete its migration to the new algorithm suite as described in this document (after the EOL of the "old" algorithm suite), its signed product set will no longer be valid. Consequently, the RPKI may, at the end of Phase 4, have a smaller number of valid signed products than before starting the process. Conversely, an RP that does not follow this process will lose the ability to validate signed products issued under the new algorithm suite. The resulting incomplete view of routing information from the RPKI (as a result of a failure by CAs or RPs to complete the transition) could degrade routing in the public Internet.
このドキュメントで説明されているように（「古い」アルゴリズムスイートのEOLの後）、CAが新しいアルゴリズムスイートへの移行を完了しない場合、署名された製品セットは無効になります。その結果、RPKIは、フェーズ4の終了時に、プロセスを開始する前よりも有効な署名済み製品の数が少なくなる可能性があります。逆に、このプロセスに従わないRPは、新しいアルゴリズムスイートで発行された署名済み製品を検証する機能を失います。 （CAまたはRPが移行を完了できなかった結果として）RPKIからのルーティング情報が不完全に表示されると、パブリックインターネットのルーティングが低下する可能性があります。
The authors would like to acknowledge the work of the SIDR working group co-chairs (Sandra Murphy, Chris Morrow, and Alexey Melnikov) as well as the contributions given by Geoff Huston, Arturo Servin, Brian Weis, Terry Manderson, Brian Dickson, David Black, and Danny McPherson.
著者は、SIDRワーキンググループの共同議長（サンドラマーフィー、クリスモロー、アレクセイメルニコフ）の仕事と、ジェフヒューストン、アルトゥーロサービン、ブライアンワイス、テリーマンダーソン、ブライアンディクソン、デビッドの寄稿に謝意を表します。ブラック、ダニー・マクファーソン。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779] Lynn、C.、Kent、S.、K。Seo、「X.509 Extensions for IP Addresses and AS Identifiers」、RFC 3779、June 2004。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、2012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482] Lepinski、M.、Kent、S.、D。Kong、「A Route for Route Origin Authorizations（ROAs）」、RFC 6482、2012年2月。
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, February 2012.
[RFC6484] Kent、S.、Kong、D.、Seo、K。、およびR. Watro、「Resource Public Key Infrastructure（RPKI）の証明書ポリシー（CP）」、BCP 173、RFC 6484、2012年2月。
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.
[RFC6485] Huston、G。、「Resource Public Key Infrastructure（RPKI）で使用するアルゴリズムとキーサイズのプロファイル」、RFC 6485、2012年2月。
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
[RFC6489] Huston、G.、Michaelson、G.、およびS. Kent、「Certification Authority（CA）Key Rollover in the Resource Public Key Infrastructure（RPKI）」、BCP 174、RFC 6489、2012年2月。
[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.
[RFC6490] Huston、G.、Weiler、S.、Michaelson、G。、およびS. Kent、「Resource Public Key Infrastructure（RPKI）Trust Anchor Locator」、RFC 6490、2012年2月。
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, February 2012.
[RFC6492] Huston、G.、Loomans、R.、Ellacott、B。、およびR. Austein、「A Protocol for Provisioning Resource Certificates」、RFC 6492、2012年2月。
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012.
[RFC6493] Bush、R。、「The Resource Public Key Infrastructure（RPKI）Ghostbusters Record」、RFC 6493、2012年2月。
Authors' Addresses
著者のアドレス
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle 1180 Switzerland
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle 1180 Switzerland
EMail: rogaglia@cisco.com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Stephen Kent BBN Technologies 10 Moulton St. Cambridge、MA 02138 USA
EMail: kent@bbn.com
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA、Inc. 3057 Nutley Street、Suite 106 Fairfax、VA 22031 USA
EMail: turners@ieca.com