[要約] Relying Parties（RPs）は、RPKI内で信頼アンカー（TA）認証局（CA）証明書を検証するためにTrust Anchor Locator（TAL）を使用します。この文書では、Trust Anchor Key（TAK）のためのRPKI署名オブジェクトが定義されています。TAは、TAKオブジェクトを使用して、現在の公開鍵のCA証明書の場所や後継の公開鍵、そのCA証明書の場所をRPに通知できます。このオブジェクトは、RPKI検証に影響を与えることなく、計画された鍵の切り替えをサポートします。
Internet Engineering Task Force (IETF) C. Martinez
Request for Comments: 9691 LACNIC
Category: Standards Track G. Michaelson
ISSN: 2070-1721 T. Harrison
APNIC
T. Bruijnzeels
RIPE NCC
R. Austein
Dragon Research Labs
December 2024
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK). A TAK object can be used by a TA to signal to RPs the location(s) of the accompanying CA certificate for the current public key, as well as the successor public key and the location(s) of its CA certificate. This object helps to support planned key rollovers without impacting RPKI validation.
Trust Anchor Locator（TAL）は、RPKI検証で使用されるTrust Anchor（TA）認証局（TA）証明書（TA）証明書を見つけて検証するために、リソース公開キーインフラストラクチャ（RPKI）に頼ることで使用されます。このドキュメントでは、Trust Anchor Key（TAK）のRPKI署名されたオブジェクトを定義します。TAKオブジェクトは、TAによって使用されて、現在の公開鍵の伴うCA証明書の位置、後継者の公開鍵とCA証明書の場所をRPSに信号することができます。このオブジェクトは、RPKIの検証に影響を与えることなく、計画されたキーロールオーバーをサポートするのに役立ちます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9691.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9691で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Overview
1.1. Requirements Notation
2. TAK Object Definition
2.1. The TAK Object Content Type
2.2. The TAK Object eContent
2.2.1. TAKey
2.2.2. TAK
2.3. TAK Object Validation
3. TAK Object Generation and Publication
4. Relying Party Use
4.1. Manual Update of TA Public Key Details
5. Maintaining Multiple TA Key Pairs
6. Performing TA Key Rolls
6.1. Phase 1: Add a TAK for Key Pair 'A'
6.2. Phase 2: Add a Key Pair 'B'
6.3. Phase 3: Update TAL to point to 'B'
6.4. Phase 4: Remove Key Pair 'A'
7. Using TAK Objects to Distribute TAL Data
8. Deployment Considerations
8.1. Relying Party Support
8.2. Alternate Transition Models
9. Operational Considerations
9.1. Acceptance Timers
10. Security Considerations
10.1. Previous Keys
10.2. TA Compromise
10.3. Alternate Transition Models
11. IANA Considerations
11.1. Content Type
11.2. Signed Object
11.3. File Extension
11.4. Module Identifier
11.5. Registration of Media Type application/rpki-signed-tal
12. References
12.1. Normative References
12.2. Informative References
Appendix A. ASN.1 Module
Acknowledgments
Authors' Addresses
A Trust Anchor Locator (TAL) [RFC8630] is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate Trust Anchor (TA) Certification Authority (CA) certificates used in RPKI validation. However, until now, there has been no in-band way of notifying RPs of updates to a TAL. In-band notifications mean that TA operators can be more confident of RPs being aware of key rollover operations.
Trust Anchor Locator（TAL）[RFC8630]は、RPKI検証で使用されているTrust Anchor（TA）認定機関（TA）認定機関（TA）証明書（TA）証明書を見つけて検証するために、リソース公開キーインフラストラクチャ（RPKI）に頼ることで使用されます。ただし、これまで、TALの更新のRPSに通知する帯域内の方法はありませんでした。帯域内通知は、TAオペレーターが主要なロールオーバー操作を認識していることに自信を持つことができることを意味します。
This document defines a new RPKI signed object that can be used to document the location(s) of the TA CA certificate for the current TA public key, as well as the value of the successor public key and the location(s) of its TA CA certificate. This allows RPs to be notified automatically of such changes and enables TAs to stage a successor public key so that planned key rollovers can be performed without risking the invalidation of the RPKI tree under the TA. We call this object the Trust Anchor Key (TAK) object.
このドキュメントでは、現在のTA公開鍵のTA CA証明書の場所、後継者の公開鍵の価値とTAの場所を文書化するために使用できる新しいRPKI署名されたオブジェクトを定義します。CA証明書。これにより、RPSをそのような変更について自動的に通知し、TASが後継者の公開キーをステージングできるようにするため、TAの下でRPKIツリーの無効化を危険にさらすことなく、計画されたキーロールオーバーを実行できます。このオブジェクトは、Trust Anchor Key（TAK）オブジェクトと呼びます。
When RPs are first bootstrapped, they use a TAL to discover the public key and location(s) of the CA certificate for a TA. The RP can then retrieve and validate the CA certificate and subsequently validate the manifest [RFC9286] and Certificate Revocation List (CRL) published by that TA (Section 5 of [RFC6487]). However, before processing any other objects, it will first validate the TAK object if it is present. If the TAK object lists only the current public key, then the RP continues processing as it would in the absence of a TAK object. If the TAK object includes a successor public key, the RP starts a 30-day acceptance timer for that key and then continues standard top-down validation with the current public key. During the following validation runs up until the expiry of the acceptance timer, the RP verifies that the public keys and the certificate URLs listed in the TAK object remain unchanged. If they remain unchanged as at that time, then the RP will fetch the successor public key, update its local state with that public key and its associated certificate location(s), and continue processing using that public key.
RPSが最初にブートストラップされると、TALを使用して、TAのCA証明書の公開鍵と場所を発見します。その後、RPはCA証明書を取得および検証し、その後、そのTA（[RFC6487]のセクション5）によって公開されたマニフェスト[RFC9286]および証明書取消リスト（CRL）を検証できます。ただし、他のオブジェクトを処理する前に、最初にTAKオブジェクトが存在する場合に検証します。TAKオブジェクトが現在の公開キーのみをリストしている場合、RPはTAKオブジェクトがない場合と同様に処理を継続します。TAKオブジェクトに後継者の公開キーが含まれている場合、RPはそのキーの30日間の受け入れタイマーを開始し、現在の公開キーで標準のトップダウン検証を継続します。以下の検証は、受け入れタイマーの有効期限が切れるまで実行されます。RPは、TAKオブジェクトにリストされている公開キーと証明書URLが変更されたままであることを確認します。それらがその時点で変更されていない場合、RPは後継者の公開キーを取得し、その公開鍵と関連する証明書の場所で地方の状態を更新し、その公開キーを使用して処理を続けます。
The primary motivation for this work is being able to migrate from a Hardware Security Module (HSM) produced by one vendor to one produced by another, where the first vendor does not support exporting private keys for use by the second. There may be other scenarios in which key rollover is useful, though.
この作業の主な動機は、あるベンダーが生成したハードウェアセキュリティモジュール（HSM）から、最初のベンダーが2番目の使用のためにプライベートキーのエクスポートをサポートしない別のベンダーが生成する1つのベンダーに移行できることです。ただし、キーロールオーバーが役立つ他のシナリオがある場合があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The TAK object makes use of the template for RPKI digitally signed objects [RFC6488], which defines a Cryptographic Message Syntax (CMS) [RFC5652] wrapper for the content, as well as a generic validation procedure for RPKI signed objects. Therefore, to complete the specification of the TAK object (see Section 4 of [RFC6488]), this document defines the following:
TAKオブジェクトは、RPKIデジタル署名されたオブジェクト[RFC6488]のテンプレートを使用します。これは、コンテンツの暗号化メッセージ構文（CMS）[RFC5652]ラッパー、およびRPKI署名されたオブジェクトの一般的な検証手順を定義します。したがって、TAKオブジェクトの仕様を完了するため（[RFC6488]のセクション4を参照）、このドキュメントは以下を定義します。
* the OID (Section 2.1) that identifies the signed object as being a TAK (this OID appears within the eContentType in the encapContentInfo object, as well as the content-type signed attribute in the signerInfo object)
* 署名されたオブジェクトをTAKであると識別するOID（セクション2.1）（このoidは、ecapcontentinfoオブジェクトのecontenttype内に表示され、signerinfoオブジェクトのコンテンツタイプの符号付き属性）
* the ASN.1 syntax for the TAK eContent (Section 2.2)
* Tak EcontentのASN.1構文（セクション2.2）
* the additional steps required to validate a TAK (Section 2.3)
* TAKを検証するために必要な追加の手順（セクション2.3）
This document specifies an OID for the TAK object as follows:
このドキュメントは、次のようにTAKオブジェクトのOIDを指定します。
id-ct-signedTAL OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 50 }
This OID MUST appear in both the eContentType in the encapContentInfo object and the content-type signed attribute in the signerInfo object (see [RFC6488]).
このoidは、ecapcontentinfoオブジェクトのecontentTypeと、SignerInfoオブジェクトのコンテンツタイプの署名属性の両方に表示する必要があります（[RFC6488]を参照）。
The content of a TAK object is ASN.1 encoded using the Distinguished Encoding Rules (DER) [X.690] and is defined per the module in Appendix A.
TAKオブジェクトの内容は、著名なエンコードルール（der）[x.690]を使用してasn.1エンコードされ、付録Aのモジュールに従って定義されています。
This structure defines a TA public key similar to that from [RFC8630]. It contains a sequence of zero or more comments, one or more certificate URIs, and a SubjectPublicKeyInfo.
この構造は、[RFC8630]のものと同様のTA公開キーを定義します。ゼロ以上のコメントのシーケンス、1つまたは複数の証明書URI、および件名PublicKeyInfoが含まれています。
comments:
コメント：
This field is semantically equivalent to the comment section defined in Section 2.2 of [RFC8630]. Each comment is human-readable informational UTF-8 text [RFC3629], conforming to the restrictions defined in Section 2 of [RFC5198]. The leading "#" character that is used to denote a comment in [RFC8630] is omitted here.
このフィールドは、[RFC8630]のセクション2.2で定義されているコメントセクションと意味的に同等です。各コメントは、[RFC5198]のセクション2で定義されている制限に準拠して、ヒューマン読み取り可能な情報uTF-8テキスト[RFC3629]です。[RFC8630]のコメントを示すために使用される主要な「＃」文字はここで省略されています。
certificateURIs:
証明書：
This field is semantically equivalent to the URI section defined in Section 2.2 of [RFC8630]. It MUST contain at least one CertificateURI element. Each CertificateURI element contains the IA5String representation of either an rsync URI [RFC5781] or an HTTPS URI [RFC9110].
このフィールドは、[RFC8630]のセクション2.2で定義されているURIセクションと意味的に同等です。少なくとも1つの証明書要素を含める必要があります。各証明書要素には、RSYNC URI [RFC5781]またはHTTPS URI [RFC9110]のいずれかのIA5STRING表現が含まれています。
subjectPublicKeyInfo:
subjectpublickeyinfo：
This field contains a SubjectPublicKeyInfo (Section 4.1.2.7 of [RFC5280]) in the DER format [X.690].
このフィールドには、der形式[x.690]にsubjectpublickeyinfo（[rfc5280]のセクション4.1.2.7）が含まれています。
version:
バージョン：
The version number of the TAK object MUST be 0.
TAKオブジェクトのバージョン番号は0でなければなりません。
current:
現在：
This field contains the TA public key of the repository in which the TAK object is published.
このフィールドには、TAKオブジェクトが公開されているリポジトリのTA公開キーが含まれています。
predecessor:
前身：
This field contains the TA public key that was in use for this TA immediately prior to the current TA public key, if applicable.
このフィールドには、該当する場合、現在のTA公開キーの直前にこのTAに使用されていたTA公開キーが含まれています。
successor:
後継：
This field contains the TA public key to be used in place of the current public key, if applicable, after expiry of the relevant acceptance timer.
このフィールドには、関連する受け入れタイマーの有効期限が切れた後、該当する場合、現在の公開キーの代わりに使用されるTA公開キーが含まれています。
To determine whether a TAK object is valid, the RP MUST perform the following checks in addition to those specified in [RFC6488]:
TAKオブジェクトが有効かどうかを判断するには、[RFC6488]で指定されたものに加えて、RPが次のチェックを実行する必要があります。
* The eContentType OID matches the OID described in Section 2.1.
* econtentType OIDは、セクション2.1で説明したOIDと一致します。
* The TAK object appears as the product of a TA CA certificate (i.e., the TA CA certificate itself is the issuer of the End-Entity (EE) certificate of the TAK object).
* TAKオブジェクトは、Ta Ca証明書の積として表示されます（つまり、Ta Ca証明書自体は、TAKオブジェクトのエンドエンティティ（EE）証明書の発行者です）。
* The TA CA has published only one TAK object in its repository for this public key, and this object appears on the manifest as the only entry using the ".tak" extension (see [RFC6481]).
* Ta Caは、この公開鍵のリポジトリに1つのTAKオブジェクトのみを公開しており、このオブジェクトは「.tak」拡張子を使用して唯一のエントリとしてマニフェストに表示されます（[RFC6481]を参照）。
* The EE certificate of this TAK object describes its Internet Number Resources (INRs) using the "inherit" attribute.
* このTAKオブジェクトのEE証明書は、「継承」属性を使用して、インターネット番号リソース（INR）を記述します。
* The decoded TAK content conforms to the format defined in Section 2.2.
* デコードされたTAKコンテンツは、セクション2.2で定義されている形式に準拠しています。
* The SubjectPublicKeyInfo value of the current TA public key in the TAK object matches that of the TA CA certificate used to issue the EE certificate of the TAK object.
* TAKオブジェクトの現在のTA公開キーの件名PublicKeyInfo値は、TAKオブジェクトのEE証明書を発行するために使用されるTA CA証明書の値と一致します。
If any of these checks do not succeed, the RP MUST ignore the TAK object and proceed as though it were not listed on the manifest.
これらのチェックのいずれかが成功しない場合、RPはTAKオブジェクトを無視し、マニフェストにリストされていないかのように進める必要があります。
The RP is not required to compare its current set of certificateURIs for the current public key with those listed in the TAK object. The RP MAY alert the user that these sets of certificateURIs do not match. If this happens, the user may opt to manually update the set of certificateURIs in their configuration. However, the RP MUST NOT automatically update its configuration to use these certificateURIs in the event of inconsistency. This is because the migration of users to new certificateURIs should happen by way of the successor public key process.
RPは、現在の公開キーの現在の証明書のセットとTAKオブジェクトにリストされているものと比較する必要はありません。RPは、これらの証明書のセットが一致しないことをユーザーに警告する場合があります。これが発生した場合、ユーザーは構成内の証明書のセットを手動で更新することを選択できます。ただし、RPは、矛盾が発生した場合にこれらの証明書を使用するように構成を自動的に更新してはなりません。これは、ユーザーの新しい証明書への移行が、後継者の公開プロセスによって行われるべきであるためです。
A non-normative guideline for naming this object is that the filename be a value derived from the public key part of the entity's key pair, using the algorithm described for CRLs in Section 2.2 of [RFC6481].
このオブジェクトを命名するための非規範的なガイドラインは、ファイル名が[RFC6481]のセクション2.2のCRLについて説明したアルゴリズムを使用して、エンティティのキーペアの公開キー部分から派生した値であることです。
The filename extension of ".tak" MUST be used to denote the object as a TAK.
「.tak」のファイル名拡張は、オブジェクトをtakとして示すために使用する必要があります。
In order to generate a TAK object, the TA MUST perform the following actions:
TAKオブジェクトを生成するには、TAは次のアクションを実行する必要があります。
* The TA MUST generate a one-time-use EE certificate for the TAK.
* TAは、TAKの1回限りのEE証明書を生成する必要があります。
* This EE certificate MUST have a unique key pair.
* このEE証明書には、一意のキーペアが必要です。
* This EE certificate MUST have a Subject Information Access (SIA) [RFC6487] extension access description field with an accessMethod OID value of id-ad-signedObject, where the associated accessLocation references the publication point of the TAK as an object URL.
* このEE証明書には、サブジェクト情報アクセス（SIA）[RFC6487]拡張アクセス説明フィールドID-AD-SignedObjectのアクセスメソッド値を持つフィールドが必要です。ここで、関連するアクセスロケーションはTAKの公開ポイントをオブジェクトURLとして参照しています。
* As described in [RFC6487], the EE certificate used for this object must contain either the IP Address Delegation extension or the Autonomous System Identifier Delegation extension [RFC3779], or both. However, because the resource set is irrelevant to this object type, this certificate MUST describe its INRs using the "inherit" attribute rather than explicitly describing a resource set.
* [RFC6487]で説明されているように、このオブジェクトに使用されるEE証明書には、IPアドレス委任拡張または自律システム識別子委任拡張[RFC3779]、またはその両方を含める必要があります。ただし、リソースセットはこのオブジェクトタイプとは無関係であるため、この証明書は、リソースセットを明示的に記述するのではなく、「継承」属性を使用してINRを記述する必要があります。
* This EE certificate MUST have a "notBefore" time that matches or predates the moment that the TAK will be published.
* このEE証明書には、TAKが公開される瞬間に一致または前にする「前に」時間がある必要があります。
* This EE certificate MUST have a "notAfter" time that reflects the intended duration for which this TAK will be published. If the EE certificate for a TAK object is expired, it MUST no longer be published, but it MAY be replaced by a newly generated TAK object with equivalent content and an updated "notAfter" time.
* このEE証明書には、このTAKが公開される意図された期間を反映する「ノートアフター」時間が必要です。TAKオブジェクトのEE証明書の有効期限が切れている場合、公開する必要はなくなりましたが、同等のコンテンツと更新された「Notafter」時間を備えた新しく生成されたTAKオブジェクトに置き換えることができます。
* The current TA public key for the TAK MUST match that of the TA CA certificate under which the TAK was issued.
* TAKの現在のTA公開鍵は、TAKが発行されたTA CA証明書の公開と一致する必要があります。
In distribution contexts that support media types, the "application/ rpki-signed-tal" media type can be used for TAK objects.
メディアタイプをサポートする配布コンテキストでは、「アプリケーション/ RPKI-SIGNED」メディアタイプをTAKオブジェクトに使用できます。
RPs MUST keep a record of the current public key for each configured TA, as well as the URI(s) where the CA certificate for this public key may be retrieved. This record is typically bootstrapped by the use of a pre-configured (and unsigned) TAL file [RFC8630].
RPSは、構成された各TAの現在の公開キーの記録と、この公開キーのCA証明書を取得できるURI（S）の記録を保持する必要があります。このレコードは通常、事前に構成された（および署名されていない）TALファイル[RFC8630]を使用することによりブートストラップされます。
When performing top-down validation, RPs MUST first validate and process the TAK object for its current known public key by performing the following steps:
トップダウン検証を実行するとき、RPSは最初に次の手順を実行して、現在の既知の公開キーのTAKオブジェクトを検証および処理する必要があります。
* A CA certificate is retrieved and validated from the known URIs as described in Sections 3 and 4 of [RFC8630].
* CA証明書は、[RFC8630]のセクション3および4で説明されているように、既知のURIから取得および検証されます。
* The manifest and CRL for this certificate are then validated as described in [RFC6487] and [RFC9286].
* この証明書のマニフェストとCRLは、[RFC6487]および[RFC9286]で説明されているように検証されます。
* If the TAK object is present, it is validated as described in Section 2.3.
* TAKオブジェクトが存在する場合、セクション2.3で説明されているように検証されます。
If the TAK object includes a successor public key, then the RP must verify the successor public key by:
TAKオブジェクトに後継者の公開鍵が含まれている場合、RPは以下の後継者を検証する必要があります。
* performing top-down validation using the successor public key in order to validate the TAK object for the successor TA,
* 後継者TAのTAKオブジェクトを検証するために、後継者の公開キーを使用してトップダウン検証を実行する、
* ensuring that a valid TAK object exists for the successor TA,
* 後継者TAに有効なTAKオブジェクトが存在するようにする、
* ensuring that the successor TAK object's current public key matches the initial TAK object's successor public key, and
* 後継者TAKオブジェクトの現在の公開キーが最初のTAKオブジェクトの後継者の公開鍵と一致するようにし、
* ensuring that the successor TAK object's predecessor public key matches the initial TAK object's current public key.
* 後継者TAKオブジェクトの前身の公開キーが、最初のTAKオブジェクトの現在の公開キーと一致するようにします。
If any of these steps fails, then the successor public key has failed verification.
これらの手順のいずれかが失敗した場合、後継者の公開鍵は検証に失敗しました。
If the successor public key passes verification and the RP has not seen that successor public key on the previous successful validation run for this TA, then the RP:
後継者の公開鍵が検証に合格し、RPがこのTAの以前の成功した検証でその後継者の公開鍵を見ていない場合、RP：
* sets an acceptance timer of 30 days for this successor public key for this TA,
* このTAの後継者の公開鍵に対して30日間の受け入れタイマーを設定します。
* cancels the existing acceptance timer for this TA (if applicable), and
* このTAの既存の受け入れタイマー（該当する場合）をキャンセルし、
* continues standard top-down validation as described in [RFC6487] using the current public key.
* 現在の公開キーを使用して[RFC6487]で説明されているように、標準のトップダウン検証を継続します。
If the successor public key passes verification and the RP has seen that successor public key on the previous successful validation run for this TA, the RP continues standard top-down validation using the current public key if the relevant acceptance timer has not expired. Otherwise, the RP updates its current known public key details for this TA to be those of the successor public key and begins top-down validation again using the successor public key.
後継者の公開キーが検証に合格し、RPがこのTAの以前の成功した検証の後継者の公開鍵を見た場合、RPは、関連する受け入れタイマーが期限切れになっていない場合、現在の公開キーを使用して標準のトップダウン検証を継続します。それ以外の場合、RPは、このTAの現在の既知の公開キーの詳細を後継者の公開鍵の詳細と更新し、後継者の公開キーを使用して再びトップダウン検証を開始します。
If the successor public key does not pass verification or if the TAK object does not include a successor public key, the RP cancels the existing acceptance timer for this TA (if applicable).
後継者の公開鍵が検証に合格しない場合、またはTAKオブジェクトに後継者の公開キーが含まれていない場合、RPはこのTAの既存の受け入れタイマーをキャンセルします（該当する場合）。
An RP MUST NOT use a successor public key for top-down validation outside of the process described above, except for the purpose of testing that the new public key is working correctly. This allows a TA to publish a successor public key for a period of time, allowing RPs to test it while still being able to rely on RPs using the current public key for their production RPKI operations.
RPは、新しい公開キーが正しく機能していることをテストする目的を除き、上記のプロセスの外側でトップダウン検証に後継者の公開キーを使用してはなりません。これにより、TAは一定期間後継者の公開鍵を公開することができ、RPSはそれをテストすることができ、現在の公開キーを使用してRPKIの生産操作を使用してRPSに依存することができます。
A successor public key may have the same SubjectPublicKeyInfo value as the current public key; this will be the case where a TA is updating the certificateURIs for that public key.
後継者の公開鍵は、現在の公開鍵と同じ件名publickeyinfo値を持っている場合があります。これは、TAがその公開キーの証明書を更新している場合になります。
An RP may opt to not support the automatic transition of TA public key data, as defined in Section 4. An alternative approach is for the RP to alert the user when a new successor public key is seen and when the relevant acceptance timer has expired. The user can then manually transition to the new TA public key data. This process ensures that the benefits of the acceptance timer period are still realised, as compared with TA public key update based on a TAL distributed out of band by a TA.
RPは、セクション4で定義されているように、TA公開キーデータの自動遷移をサポートしないことを選択する場合があります。代替アプローチは、RPが新しい後継者公開キーが見られ、関連する受け入れタイマーが期限切れになったときにユーザーに警告することです。ユーザーは、新しいTA公開キーデータに手動で移行できます。このプロセスにより、TAがバンドから配布されたTALに基づくTA公開キーの更新と比較して、受け入れタイマー期間の利点がまだ実現されます。
An RP that can process TAK objects will only ever use one public key for validation: either the current public key, or the successor public key once the relevant acceptance timer has expired. By contrast, an RP that cannot process TAK objects will continue to use the public key details per its TAL (or equivalent manual configuration) indefinitely. As a result, even when a TA is using a TAK object in order to migrate clients to a new public key, the TA may have to maintain the previous key pair for a period of time alongside the new key pair in order to ensure continuity of service for older clients.
TAKオブジェクトを処理できるRPは、検証に1つの公開キーのみを使用します。関連する受け入れタイマーの有効期限が切れた場合、現在の公開キーまたは後継者の公開鍵のいずれかです。対照的に、TAKオブジェクトを処理できないRPは、TAL（または同等のマニュアル構成）ごとに公開キーの詳細を無期限に使用し続けます。その結果、TAがクライアントを新しい公開キーに移行するためにTAKオブジェクトを使用している場合でも、TAは以前のキーペアを、新しいキーペアと一緒に一定期間維持する必要がある場合があります。古いクライアント向けのサービス。
For each TA key pair that a TA maintains, the signed material for these key pairs MUST be published under different directories in the context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' SIA descriptions contained on the CA certificates [RFC6487]. Publishing objects under the same directory is potentially confusing for RPs and could lead to object invalidity in the event of filename collisions.
TAが維持する各TAキーペアについて、これらのキーペアの署名された資料は、CA証明書に含まれる「ID-AD-CarePository」および「ID-AD-RPKIMANIFEST」SIA説明のコンテキストで、さまざまなディレクトリの下で公開する必要があります。[RFC6487]。同じディレクトリの下でオブジェクトを公開することは、RPSにとって潜在的に混乱しており、ファイル名の衝突が発生した場合にオブジェクトの無効につながる可能性があります。
Also, the CA certificates for each maintained key pair and the content published for each key pair MUST be equivalent (except for the TAK object). In other words, for the purposes of RPKI validation, it MUST NOT make a difference which of the public keys is used as a starting point.
また、維持されている各キーペアのCA証明書と各キーペアに対して公開されたコンテンツは同等でなければなりません（TAKオブジェクトを除く）。言い換えれば、RPKI検証の目的のために、どのパブリックキーが出発点として使用されるかを違いさせてはなりません。
This means that the IP and Autonomous System (AS) resources contained on all current CA certificates for the maintained TA key pairs MUST be the same. Furthermore, for any delegation of IP and AS resources to a child CA, the TA MUST have an equivalent CA certificate published under each of its key pairs. Any updates in delegations MUST be reflected under each of its key pairs. A TA SHOULD NOT publish any other objects besides a CRL, a manifest, a single TAK object, and any number of CA certificates for delegation to child CAs.
これは、保守されているTAキーペアの現在のすべてのCA証明書に含まれるIPおよび自律システム（AS）リソースが同じでなければならないことを意味します。さらに、IPの委任および子どもCAへのリソースとしての場合、TAはそれぞれのキーペアの下で同等のCA証明書を公開する必要があります。代表団の更新は、それぞれのキーペアの下に反映される必要があります。TAは、CRL、マニフェスト、単一のTAKオブジェクト、および委任のための任意の数のCA証明書以外の他のオブジェクトを公開してはなりません。
If a TA uses a single remote publication server (per [RFC8181]) for its key pairs, then it MUST include all <publish/> and <withdraw/> Protocol Data Units (PDUs) for the products of each of its key pairs in a single query in order to reduce the risk of RPs seeing inconsistent data in the TA's RPKI repositories.
TAが重要なペアに単一のリモートパブリケーションサーバー（[RFC8181]ごとに）を使用する場合、それぞれのキーペアの製品にすべての<publish/> and <rebult/>プロトコルデータユニット（PDU）を含める必要があります。RPSがTAのRPKIリポジトリに一貫性のないデータを見るリスクを減らすための単一のクエリ。
If a TA uses multiple publication servers, then the content for different key pairs will be out of sync at times. The TA SHOULD ensure that the duration of these moments is limited to the shortest possible time. Furthermore, the following should be observed:
TAが複数の公開サーバーを使用する場合、異なるキーペアのコンテンツは時々同期しなくなります。TAは、これらの瞬間の期間が可能な限り短い時間に制限されるようにする必要があります。さらに、以下を観察する必要があります。
* In cases where a CA certificate is revoked or replaced by a certificate with a reduced set of resources, these changes will not take effect fully until all the relevant repository publication points have been updated. Given that TA private key operations are normally performed infrequently, this is unlikely to be a problem: if the revocation or shrinking of an issued CA certificate is staged for days/weeks, then experiencing a delay of several minutes for the repository publication points to be updated is relatively insignificant.
* CA証明書が取り消されるか、リソースのセットが削減された証明書に置き換えられた場合、これらの変更はすべての関連するリポジトリの公開ポイントが更新されるまで完全に有効になりません。TA秘密キー操作が通常頻繁に実行されることはないことを考えると、これは問題になる可能性は低いです。発行されたCA証明書の取消または縮小が数日/週にわたってステージングされている場合、リポジトリの公開ポイントの数分の遅延が発生します。更新は比較的重要ではありません。
* In cases where a CA certificate is replaced by a certificate with an extended set of resources, the TA MUST inform the receiving CA only after all of its repository publication points have been updated. This ensures that the receiving CA will not issue any products that could be invalid if an RP uses a TA public key just before the CA certificate was due to be updated.
* CA証明書が拡張されたリソースセットを備えた証明書に置き換えられる場合、TAは、リポジトリの公開ポイントがすべて更新された後にのみ、受信CAに通知する必要があります。これにより、RPがCA証明書が更新される直前にTA公開キーを使用する場合、受信CAが無効になる可能性のある製品を発行しないことが保証されます。
Finally, note that the publication locations of CA certificates for delegations to child CAs under each key pair will be different; therefore, the Authority Information Access 'id-ad-caIssuers' values (Section 4.8.7 of [RFC6487]) on certificates issued by the child CAs may not be as expected when performing top-down validation, depending on the TA public key that is used. However, these values are not critical to top-down validation, so RPs performing such validation MUST NOT reject a certificate simply because this value is not as expected.
最後に、各キーペアの下で子供CAの代表団のCA証明書の出版場所は異なることに注意してください。したがって、権限情報は、子のCASによって発行された証明書に「ID-AD-CAISSUERS」の値（[RFC6487]のセクション4.8.7）にアクセスすることは、トップダウン検証を実行するときに予想通りではない場合があります。使用されています。ただし、これらの値はトップダウン検証にとって重要ではないため、この値を実行するRPSを実行することは、この値が予想どおりではないという理由だけで証明書を拒否してはなりません。
This section describes how present-day RPKI TAs that use only one key pair and do not use TAK objects can use a TAK object to perform a planned key rollover.
このセクションでは、1つのキーペアのみを使用し、TAKオブジェクトを使用しない現在のRPKI TASがTAKオブジェクトを使用して、計画されたキーロールオーバーを実行する方法について説明します。
Before adding a successor public key, a TA may want to confirm that it can maintain a TAK object for its current key pair only. We will refer to this key pair as key pair 'A' throughout this section.
後継者の公開鍵を追加する前に、TAは現在のキーペアのみのTAKオブジェクトを維持できることを確認することをお勧めします。このセクション全体で、このキーペアをキーペア「A」と呼びます。
The TA can now generate a new key pair called 'B'. The private key of this key pair MUST now be used to create a new CA certificate for the associated public key and issue equivalent CA certificates for delegations to child CAs as described in Section 5.
TAは、「B」と呼ばれる新しいキーペアを生成できるようになりました。このキーペアの秘密鍵を使用して、関連する公開キーの新しいCA証明書を作成し、セクション5で説明されているように、子供CASに代表団の同等のCA証明書を発行する必要があります。
At this point, the TA can also construct a new TAL file [RFC8630] for the public key of key pair 'B' and locally test that the validation outcome for the new public key is equivalent to that of the other current public key(s).
この時点で、TAはキーペア「B」の公開キーの新しいTALファイル[RFC8630]を構築し、新しい公開キーの検証結果は他の現在の公開キーの結果と同等であることをローカルにテストすることもできます（s）。
When the TA is certain that the content for both public keys is equivalent and wants to initiate the migration from 'A' to 'B', it issues a new TAK object under key pair 'A', with the public key from that key pair as the current public key for that object, the public key from key pair 'B' as the successor public key, and no predecessor public key. It also issues a TAK object under key pair 'B', with the public key from that key pair as the current public key for that object, the public key from key pair 'A' as the predecessor public key, and no successor public key.
TAが両方のパブリックキーのコンテンツが同等であり、「A」から「B」への移行を開始したいと確信している場合、キーペアの公開キーを使用して、キーペア「A」の下に新しいTAKオブジェクトを発行します。そのオブジェクトの現在の公開鍵として、キーペア「B」からの公開鍵は後継者の公開鍵として、そして前任者の公開鍵はありません。また、キーペア「B」の下にTAKオブジェクトを発行します。そのキーペアの公開キーは、そのオブジェクトの現在の公開キーとして、キーペアの公開キー「A」が前身の公開鍵として、そして後継者の公開鍵はありません。
Once this has happened, RP clients will start seeing the new public key and setting acceptance timers accordingly.
これが起こると、RPクライアントは新しい公開キーを見て、それに応じて受け入れタイマーを設定し始めます。
At about the time that the TA expects clients to start setting the public key from key pair 'B' as the current public key, the TA must release a new TAL file for that public key. It SHOULD use a different set of URIs in the TAL compared to the TAK file so that the TA can learn the proportion of RPs that can successfully validate and use the updated TAK objects.
TAがクライアントがキーペア「B」から公開キーの設定を現在の公開鍵として設定することを期待する頃に、TAはその公開鍵の新しいTALファイルをリリースする必要があります。TAKファイルと比較して、TALで異なるURIのセットを使用して、更新されたTAKオブジェクトを正常に検証および使用できるRPSの割合を学習できるようにする必要があります。
To support RPs that do not take account of TAK objects, the TA should continue operating key pair 'A' for a period of time after the expected migration of clients to the public key from 'B'. The length of that period of time is a local policy matter for that TA: for example, it might operate the key pair until no clients are attempting to validate using the associated public key.
TAKオブジェクトを考慮しないRPSをサポートするには、TAは、「B」から公開キーにクライアントが移行すると、一定期間キーペア「A」を操作し続ける必要があります。その期間の長さは、そのTAのローカルポリシーの問題です。たとえば、関連する公開キーを使用して検証しようとするクライアントがいないまで、キーペアを操作する可能性があります。
The TA SHOULD now remove all content from the repository used by key pair 'A' and destroy the private key for that key pair. RPs attempting to rely on a TAL for the public key from key pair 'A' from this point will not be able to perform RPKI validation for the TA and will have to update their local state manually by way of a new TAL file.
TAは、キーペア「A」で使用されているリポジトリからすべてのコンテンツを削除し、そのキーペアの秘密鍵を破壊する必要があります。この時点からキーペア「A」から公開キーのTALに依存しようとするRPSは、TAに対してRPKI検証を実行することができず、新しいTALファイルを介して現地の状態を手動で更新する必要があります。
RPs must be configured with RPKI TA data in order to function correctly. This TA data is typically distributed in the TAL format defined in [RFC8630]. A TAK object can also serve as a format for distribution of this data, though, because the TAKey data stored in the TAK object contains the same data that would appear in a TAL for the associated TA.
正しく機能するには、RPSをRPKI TAデータで構成する必要があります。このTAデータは、通常、[RFC8630]で定義されているTAL形式で分布しています。ただし、TAKオブジェクトに格納されているTAKオブジェクトに保存されているデータには、関連するTAのTALに表示される同じデータが含まれているため、TAKオブジェクトはこのデータの配布の形式としても機能します。
RPs may support conversion of TAK objects into TAL files. RPs that support conversion MUST validate the TAK object using the process from Section 2.3. One exception to the standard validation process in this context is that an RP MAY treat a TAK object as valid, even though it is associated with a TA that the RP is not currently configured to trust. If the RP is relying on this exception when converting a given TAK object, the RP MUST communicate that fact to the user.
RPSは、TAKオブジェクトのTALファイルへの変換をサポートする場合があります。コンバージョンをサポートするRPSは、セクション2.3のプロセスを使用してTAKオブジェクトを検証する必要があります。このコンテキストでの標準検証プロセスの1つの例外は、RPが現在信頼できるように構成されていないことがTAに関連付けられていても、RPがTAKオブジェクトを有効なものとして扱うことができることです。特定のTAKオブジェクトを変換するときにRPがこの例外に依存している場合、RPはその事実をユーザーに伝える必要があります。
When converting a TAK object, an RP MUST default to producing a TAL file based on the 'current' TAKey in the TAK object, though it MAY optionally support producing TAL files based on the 'predecessor' and 'successor' TAKeys.
TAKオブジェクトを変換する場合、RPは、TAKオブジェクトの「現在」のTakeyに基づいてTALファイルをデフォルトで作成する必要がありますが、「前身」と「後継者」のTakeysに基づいてTALファイルの生成をサポートする場合があります。
If the TAKey that is being converted has comments, an RP MUST include those comments in the TAL file.
変換されているTakeyにコメントがある場合、RPにはTALファイルにそれらのコメントを含める必要があります。
If TAK object validation fails, then the RP MUST NOT produce a TAL file based on the TAK object.
TAKオブジェクトの検証が失敗した場合、RPはTAKオブジェクトに基づいてTALファイルを作成してはなりません。
Users should be aware that TAK objects distributed out of band have similar security properties to TAL files (i.e., there is no authentication). In particular, TAK objects that are not signed by TAs with which the RP is currently configured should only be used if the source that distributes them is one the user trusts to distribute TAL files.
ユーザーは、バンドから分散したTAKオブジェクトには、TALファイルと同様のセキュリティプロパティがあることに注意する必要があります（つまり、認証はありません）。特に、RPが現在構成されているTASによって署名されていないTAKオブジェクトは、それらを配布するソースがユーザーがTALファイルを配布するために信頼する場合にのみ使用する必要があります。
If an RP is not transitioning to new TA data using the automatic process described in Section 4 or the partially manual process described in Section 4.1, then the user will have to rely on an out-of-band mechanism for validating and updating the TA data for the RP. Users in this situation should take similar care when updating a TA using a TAK object file as when using a TAL file to update TA data.
RPがセクション4で説明されている自動プロセスまたはセクション4.1で説明されている部分的に手動プロセスを使用して新しいTAデータに遷移していない場合、ユーザーはTAデータを検証および更新するためのバンド外メカニズムに依存する必要があります。RPの場合。この状況のユーザーは、TAKオブジェクトファイルを使用してTAKファイルを使用してTAファイルを使用してTAデータを更新する場合と同様の注意を払う必要があります。
Publishing TAK objects while RPs do not support this standard will result in those RPs rejecting these objects. It is not expected that this will result in the invalidation of any other object under a TA.
TAKオブジェクトの公開RPSはこの標準をサポートしていませんが、これらのRPSはこれらのオブジェクトを拒否します。これにより、TAの下で他のオブジェクトが無効になることは予想されません。
Some RPs may purposefully not support this mechanism: for example, they may be implemented or configured such that they are unable to update local current public key data. TA operators should take this into consideration when planning key rollover. However, these RPs would ideally still notify their operators of planned key rollovers so that the operator could update the relevant configuration manually.
一部のRPSは、意図的にこのメカニズムをサポートしていない場合があります。たとえば、現地の現在の公開キーデータを更新できないように実装または構成されている場合があります。TAオペレーターは、キーロールオーバーを計画する際にこれを考慮に入れる必要があります。ただし、これらのRPSは、オペレーターが関連する構成を手動で更新できるように、計画されたキーロールオーバーをオペレーターに通知するのが理想的です。
Alternate models for TAL update exist and are complementary to this mechanism. For example, TAs can liaise directly with RP software developers to include updated and reissued TAL files in new code releases and use existing code update mechanisms in the RP community to distribute the changes.
TALアップデートの代替モデルが存在し、このメカニズムを補完します。たとえば、TASはRPソフトウェア開発者と直接連絡して、新しいコードリリースに更新および再発行されたTALファイルを含めることができ、RPコミュニティで既存のコード更新メカニズムを使用して変更を分散させることができます。
Additionally, these non-TA channels for distributing TAL data may themselves monitor for TAK objects and then update the TAL data in their distributions or packages accordingly. In this way, TAK objects may be useful even for RPs that don't implement in-band support for the protocol.
さらに、TALデータを配布するためのこれらの非TAチャネル自体がTAKオブジェクトを監視し、それに応じて分布またはパッケージのTALデータを更新する場合があります。このようにして、TAKオブジェクトは、プロトコルのバンド内サポートを実装していないRPSにとっても役立つ場合があります。
Non-TA channels for distributing TAL data should ensure, so far as is possible, that their update mechanisms take account of any changes that a user has made to their local TA public key configuration. For example, if a new public key is published for a TA, but the non-TA channel's mechanism is able to detect that a user had removed the TA's previous public key from their local TA public key configuration such that the user no longer relies on it, then the mechanism should not add the new public key to the user's TA public key configuration by default.
TALデータを配信するための非TAチャネルは、可能な限り、ユーザーがローカルTA公開キー構成に対して行った変更を考慮していることを可能にする必要があります。たとえば、TA用に新しい公開キーが公開されている場合、非TAチャネルのメカニズムは、ユーザーがローカルTAの公開キー構成からTAの以前の公開キーを削除したことを検出できます。これにより、メカニズムは、デフォルトでユーザーのTA公開キーの構成に新しい公開キーを追加してはなりません。
Acceptance timers are used in TAK objects in order to permit RPs to test that the new public key is working correctly. In turn, this means that the TA operator will be able to gain confidence in the correct functioning of the new public key before RPs are relying on that public key in their production RPKI operations. If a successor public key is not working correctly, a TA may remove that public key from the current TAK object.
RPSが新しい公開キーが正しく機能していることをテストすることを許可するために、TAKオブジェクトで受け入れタイマーが使用されます。次に、これは、RPSが生産RPKI運用の公開キーに依存する前に、TAオペレーターが新しい公開キーの正しい機能に自信を持つことができることを意味します。後継の公開鍵が正しく機能していない場合、TAは現在のTAKオブジェクトからその公開キーを削除する場合があります。
A TA that removes a successor public key from a TAK object SHOULD NOT add the same successor public key back into the TAK object for that TA. This is because there may be an RP that has fetched the TAK object while the successor public key was listed in it and has started an acceptance timer accordingly but has not fetched the TAK object during the period when the successor public key was not listed in it. If the unchanged successor public key is added back into the TA, such an RP will transition to using the new TA public key more quickly than other RPs, which may make debugging and similar processes more complicated. A simple way of addressing this problem in a situation where the TA operator doesn't want to reissue the SubjectPublicKeyInfo content for the successor public key that was withdrawn is to update the URL set for the successor public key. Since RPs must take that URL set into account for the purposes of initiating and cancelling acceptance timers, an RP that observes a change to that URL set will cancel any existing acceptance timer it has and initiate a new acceptance timer in its place.
TAKオブジェクトから後継者の公開キーを削除するTAは、同じ後継者の公開鍵をそのTAのTAKオブジェクトに戻してはなりません。これは、後継者の公開鍵がリストされ、それに応じて受け入れタイマーを開始したが、後継者の公開鍵がリストされていない期間中にTAKオブジェクトを取得していない間に、TAKオブジェクトを取得したRPがある可能性があるためです。変更されていない後継者の公開キーがTAに追加された場合、そのようなRPは、他のRPSよりも迅速に新しいTA公開キーを使用するように移行します。これにより、デバッグや同様のプロセスがより複雑になります。TAオペレーターが、撤回された後継者の公開鍵の件名PublicKeyInfoコンテンツを再発行したくない状況で、この問題に対処する簡単な方法は、後継者の公開鍵のURLセットを更新することです。RPSはそのURLセットを考慮に入れて受け入れタイマーを開始およびキャンセルする目的で考慮しなければならないため、そのURLセットの変更を観察するRPは、既存の受け入れタイマーをキャンセルし、その代わりに新しい受け入れタイマーを開始します。
A TA needs to consider the length of time for which it will maintain previously current key pairs and their associated repositories. An RP that is seeded with old TAL data will run for 30 days using the previous public key before migrating to the next public key due to the acceptance timer requirements, and this 30-day delay applies to each new key pair that has been issued since the old TAL data was initially published. In these instances, it may be better for the TA to send error responses when receiving requests for the old publication URLs so that the RP reports an error to its operator and the operator seeds it with up-to-date TAL data immediately.
TAは、以前に現在のキーペアと関連するリポジトリを維持する時間の長さを考慮する必要があります。古いTALデータでシードされたRPは、受け入れタイマーの要件のために次の公開キーに移行する前に以前の公開キーを使用して30日間実行され、この30日間の遅延は、それ以降発行されている新しいキーペアに適用されます。古いTALデータが最初に公開されました。これらの例では、古い公開URLのリクエストを受信するときにTAがエラー応答を送信する方が良い場合があるため、RPはオペレーターにエラーを報告し、オペレーターはすぐに最新のTALデータをシードします。
Once a TA has decided not to maintain a previously current key pair and its associated repository, the TA SHOULD destroy the associated private key. The TA SHOULD also reuse the TA CA certificate URLs from the previous TAL data for the next TAL that it generates. These measures will help to mitigate the risk of an adversary gaining access to the private key and its associated publication points in order to send invalid or incorrect data to RPs seeded with the TAL data for the corresponding public key.
TAが以前に現在のキーペアとそれに関連するリポジトリを維持しないことを決定したら、TAは関連する秘密鍵を破壊するはずです。また、TAは、それが生成する次のTALのために、以前のTALデータのTA CA証明書URLを再利用する必要があります。これらの措置は、対応する公開鍵のTALデータに播種されたRPSに無効または誤ったデータを送信するために、敵が秘密鍵とそれに関連する出版ポイントにアクセスできるリスクを軽減するのに役立ちます。
TAK objects do not offer protection against compromise of the current TA private key or the successor TA private key. TA private key compromise in general is out of scope for this document.
TAKオブジェクトは、現在のTA秘密鍵または後継者TAプライベートキーの妥協に対する保護を提供しません。一般的に、TA秘密のキーの妥協は、このドキュメントの範囲外です。
While it is possible for a malicious actor to use TAK objects to cause RPs to transition from the current TA public key to a successor TA public key, such action is predicated on the malicious actor having compromised the current TA private key in the first place. Since a malicious actor who has compromised the current TA private key has complete control over the TA anyway, TAK objects do not alter the security considerations relevant to this scenario.
悪意のある俳優がTAKオブジェクトを使用してRPSを現在のTAの公開鍵から後継者TAの公開鍵に移行させる可能性がありますが、そのようなアクションは、そもそも現在のTAの秘密鍵を侵害した悪意のある俳優に基づいています。とにかく、現在のTAの秘密鍵を妥協した悪意のある俳優は、TAを完全に制御しているため、TAKオブジェクトはこのシナリオに関連するセキュリティに関する考慮事項を変更しません。
Section 8.2 describes other ways in which a TA may transition from one key pair to another. Transition by way of an in-band process reliant on TAK objects is not mandatory for TAs or RPs, though the fact that the TAK objects are verifiable by way of the currently trusted TA public key is a benefit compared with existing out-of-band mechanisms for TA public key distribution.
セクション8.2では、TAが1つのキーペアから別のペアに移行する他の方法について説明します。TAKオブジェクトに依存している帯域内プロセスによる移行は、TASまたはRPSには必須ではありませんが、TAKオブジェクトが現在信頼されているTA公開鍵によって検証可能であるという事実は、既存の帯域外帯と比較して利点です。TA公開キー配布のメカニズム。
There will be a period of time where both the current public key and the successor public key are available for use, and RPs that are initialised at different points of the transition process or from different out-of-band sources may be using either the current public key or the successor public key. TAs are required to ensure, so far as is possible, that RPKI validation outcomes are the same regardless of which of the two keys is used.
現在の公開キーと後継キーの両方が使用できる期間があり、移行プロセスの異なるポイントで初期化されたRPSまたはバンド外の異なるソースからのRPSが現在のものを使用している場合があります公開鍵または後継者の公開鍵。TASは、可能な限り、RPKIの検証結果が2つのキーのどれが使用されているかに関係なく同じであることを確認する必要があります。
IANA has registered an OID for one content type in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry as follows:
IANAは、「S/MIME CMSコンテンツタイプのSMIセキュリティ（1.2.840.113549.1.9.16.1）」の1つのコンテンツタイプのOIDを登録しました。
+=========+=================+=============+
| Decimal | Description | References |
+=========+=================+=============+
| 50 | id-ct-signedTAL | Section 2.1 |
+---------+-----------------+-------------+
Table 1
Description:
説明：
id-ct-signedTAL
id-ct-signedtal
OID:
OID:
1.2.840.113549.1.9.16.1.50
1.2.840.113549.1.9.16.1.50
Specification:
仕様：
Section 2.1
セクション2.1
IANA has added the following to the "RPKI Signed Objects" registry:
IANAは、「RPKI署名されたオブジェクト」レジストリに以下を追加しました。
+==================+============================+=============+
| Name | OID | Reference |
+==================+============================+=============+
| Trust Anchor Key | 1.2.840.113549.1.9.16.1.50 | Section 2.1 |
+------------------+----------------------------+-------------+
Table 2
IANA has also added the following note to the "RPKI Signed Objects" registry:
IANAは、「RPKI署名されたオブジェクト」レジストリに次のメモを追加しました。
Objects of the types listed in this registry, as well as RPKI resource certificates and CRLs, are expected to be validated using the RPKI.
このレジストリにリストされているタイプのオブジェクトと、RPKIリソース証明書とCRLは、RPKIを使用して検証されると予想されます。
IANA has added the following item for the Signed TAL file extension to the "RPKI Repository Name Schemes" registry created by [RFC6481]:
IANAは、[RFC6481]によって作成された「RPKIリポジトリ名スキーム」レジストリに署名されたTALファイル拡張機能の次のアイテムを追加しました。
+====================+==================+===========+
| Filename Extension | RPKI Object | Reference |
+====================+==================+===========+
| .tak | Trust Anchor Key | RFC 9691 |
+--------------------+------------------+-----------+
Table 3
IANA has registered an OID for one module identifier in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry as follows:
IANAは、「S/MIMEモジュール識別子のSMIセキュリティ（1.2.840.113549.1.9.16.0）」の1つのモジュール識別子のOIDを登録しました。
+=========+================================+============+
| Decimal | Description | References |
+=========+================================+============+
| 74 | RPKISignedTrustAnchorList-2021 | RFC 9691 |
+---------+--------------------------------+------------+
Table 4
Description:
説明：
RPKISignedTrustAnchorList-2021
rpkisignedtrustanchorlist-2021
OID:
OID:
1.2.840.113549.1.9.16.0.74
1.2.840.113549.1.9.16.0.74
Specification:
仕様：
RFC 9691
RFC 9691
IANA has registered the media type "application/rpki-signed-tal" in the "Media Types" registry as follows:
IANAは、次のように、「メディアタイプ」レジストリにメディアタイプ「アプリケーション/rpki-signed-tal」を登録しています。
Type name:
タイプ名：
application
応用
Subtype name:
サブタイプ名：
rpki-signed-tal
rpki-signed-tal
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
binary
バイナリ
Security considerations:
セキュリティ上の考慮事項：
Carries an RPKI Signed TAL. This media type contains no active content. See the Security Considerations section of RFC 9691 for further information.
RPKI署名されたTALを運びます。このメディアタイプには、アクティブなコンテンツが含まれていません。詳細については、RFC 9691のセキュリティに関する考慮事項セクションを参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9691
RFC 9691
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
RPKI operators
RPKIオペレーター
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Content:
コンテンツ：
This media type is for a signed object, as defined in RFC 6488, which contains trust anchor key material as defined in RFC 9691.
このメディアタイプは、RFC 6488で定義されている署名されたオブジェクト用です。これには、RFC 9691で定義されているトラストアンカーキー資料が含まれています。
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
.tak
.tak
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
iesg@ietf.org
iesg@ietf.org
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
N/A
n/a
Author:
著者：
sidrops WG
Sidrops Wg
Change controller:
Change Controller：
IESG
iesg
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<https://www.rfc-editor.org/info/rfc5198>.
[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>.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
<https://www.rfc-editor.org/info/rfc5781>.
[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>.
[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>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication
Protocol for the Resource Public Key Infrastructure
(RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017,
<https://www.rfc-editor.org/info/rfc8181>.
[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
August 2019, <https://www.rfc-editor.org/info/rfc8630>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
<https://www.rfc-editor.org/info/rfc9286>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
February 2021,
<https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
DOI 10.17487/RFC5911, June 2010,
<https://www.rfc-editor.org/info/rfc5911>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
This appendix includes the ASN.1 module for the TAK object.
この付録には、TAKオブジェクトのASN.1モジュールが含まれています。
RPKISignedTrustAnchorList-2021
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) mod(0) 74 }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
CONTENT-TYPE
FROM CryptographicMessageSyntax-2009 -- in [RFC5911]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }
SubjectPublicKeyInfo
FROM PKIX1Explicit-2009 -- in [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) } ;
ct-signedTAL CONTENT-TYPE ::=
{ TYPE TAK IDENTIFIED BY
id-ct-signedTAL }
id-ct-signedTAL OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 50 }
CertificateURI ::= IA5String
TAKey ::= SEQUENCE {
comments SEQUENCE SIZE (0..MAX) OF UTF8String,
certificateURIs SEQUENCE SIZE (1..MAX) OF CertificateURI,
subjectPublicKeyInfo SubjectPublicKeyInfo
}
TAK ::= SEQUENCE {
version INTEGER DEFAULT 0,
current TAKey,
predecessor [0] TAKey OPTIONAL,
successor [1] TAKey OPTIONAL
}
END
The authors wish to thank Martin Hoffmann for a thorough review of the document, Russ Housley for multiple reviews of the ASN.1 definitions and for providing a new module for the TAK object, Job Snijders for the extensive suggestions around TAK object structure/ distribution and rpki-client implementation work, and Ties de Kock for text/suggestions around TAK/TAL distribution and general security considerations.
著者は、ドキュメントの徹底的なレビュー、asn.1の定義の複数のレビュー、およびtakオブジェクトの新しいモジュールを提供してくれたこと、TAKオブジェクトの構造/分布に関する広範な提案のためのジョブスニッダースの提供について、Martin Hoffmannに感謝したいと考えています。RPKI-Clientの実装作業、およびTAK/TALの分布と一般的なセキュリティに関する考慮事項に関するテキスト/提案のためにDe Kockを結び付けます。
Carlos Martinez
LACNIC
Rambla Mexico 6125
11400 Montevideo
Uruguay
Email: carlos@lacnic.net
URI: https://www.lacnic.net/
George G. Michaelson
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Email: ggm@apnic.net
Tom Harrison
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Email: tomh@apnic.net
Tim Bruijnzeels
RIPE NCC
Stationsplein 11
Amsterdam
The Netherlands
Email: tim@ripe.net
URI: https://www.ripe.net/
Rob Austein
Dragon Research Labs
Email: sra@hactrn.net