[要約] RFC 6489は、RPKIにおけるCAキーロールオーバーに関するガイドラインです。その目的は、セキュリティと信頼性を確保しながら、RPKIのCAキーを更新する方法を提供することです。
Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6489 G. Michaelson
BCP: 174 APNIC
Category: Best Current Practice S. Kent
ISSN: 2070-1721 BBN
February 2012
Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)
認証機関（CA）リソース公開キーインフラストラクチャ（RPKI）のキーロールオーバー
Abstract
概要
This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs.
このドキュメントでは、リソース公開キーインフラストラクチャ（RPKI）の認証機関（CA）が、キーペアの計画的なロールオーバーを実行する方法について説明します。このドキュメントには、依存関係者（RPS）に対するこの重要なロールオーバー手順の意味もあります。一般に、RPSは、RPKIリポジトリで公開されているオブジェクトのローカルキャッシュを維持することが期待されています。したがって、CAがキーロールオーバーを実行する方法はRPSに影響を与えます。
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）の製品です。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/rfc6489.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6489で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eのセクション4で説明されているように、簡略化されたBSDライセンステキストを含める必要があります。
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
信頼の法的規定と、簡略化されたBSDライセンスに記載されているように、保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology and Concepts ...................................2
2. CA Key Rollover Procedure .......................................3
3. Relying Party Requirements ......................................6
4. Reissuing Certificates and RPKI Signed Objects ..................7
4.1. CA Certificates ............................................7
4.2. RPKI Signed Objects ........................................7
5. Security Considerations .........................................8
6. Acknowledgements ................................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
This document describes an algorithm to be employed by a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) [RFC6480] to perform a rollover of its key pair.
このドキュメントでは、キーペアのロールオーバーを実行するために、リソース公開キーインフラストラクチャ（RPKI）[RFC6480]の認証機関（CA）が採用するアルゴリズムについて説明します。
This document defines a conservative procedure for such entities to follow when performing a key rollover. This procedure is "conservative" in that the CA's actions in key rollover are not intended to disrupt the normal operation of relying parties (RPs) in maintaining a local cached version of the RPKI distributed repository. Using this procedure, RPs are in a position to be able to validate all authentic objects in the RPKI using the validation procedure described in [RFC6480] at all times.
このドキュメントは、キーロールオーバーを実行するときにそのようなエンティティが従うべき保守的な手順を定義しています。この手順は、キーロールオーバーでのCAの行動が、RPKI分散リポジトリのローカルキャッシュバージョンの維持における依存関係者（RPS）の通常の運用を混乱させることを意図していないという点で「保守的」です。この手順を使用して、RPSは、[RFC6480]で説明されている検証手順を常に使用して、RPKI内のすべての本物のオブジェクトを検証できる立場にあります。
It is assumed 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], the profile for RPKI Certificates [RFC6487], and the RPKI repository structure [RFC6481] .
読者は、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」[RFC5280]、「IPアドレスおよび識別子としてのX.509拡張機能」[RFC5280]に記載されている用語と概念に精通していると想定されています。RFC3779]、RPKI証明書[RFC6487]のプロファイル、およびRPKIリポジトリ構造[RFC6481]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
A CA in the RPKI is an entity that issues CA and end-entity (EE) certificates and Certificate Revocation Lists (CRLs). A CA instance is associated with a single key pair [RFC6487], implying that if key rollover is a regularly scheduled event, then, over time, there will be many CA instances. The implication in the context of key rollover is that, strictly speaking, a CA does not perform a key rollover per se. In order to perform the equivalent of a key rollover, the CA creates a "new" instance of itself, with a new key pair, and then effectively substitutes this "new" CA instance into the RPKI hierarchy in place of the "old" CA instance.
RPKIのCAは、CAおよびEnd-Entity（EE）証明書と証明書の取り消しリスト（CRL）を発行するエンティティです。CAインスタンスは、単一のキーペア[RFC6487]に関連付けられており、キーロールオーバーが定期的にスケジュールされたイベントである場合、時間の経過とともに多くのCAインスタンスがあることを意味します。キーロールオーバーのコンテキストでの意味は、厳密に言えば、CAがキーロールオーバー自体を実行しないことです。キーロールオーバーに相当するものを実行するために、CAは新しいキーペアを使用して「新しい」インスタンスを作成し、「古い」CAの代わりにこの「新しい」CAインスタンスをRPKI階層に効果的に置き換えます。実例。
Note that focus of this procedure is planned key rollover, not an emergency key rollover, e.g., promoted by a suspected or detected private key compromise. However, the procedure described here is applicable in emergency key rollover situations, with the exception of the "Staging Period" duration.
この手順の焦点は、緊急のキーロールオーバーではなく、キーロールオーバーが計画されていることに注意してください。ただし、ここで説明する手順は、「ステージング期間」期間を除き、緊急キーロールオーバーの状況に適用できます。
There are several considerations regarding this procedure that MUST be followed by a CA performing a key rollover operation. The critical consideration is that the RPKI has potential application in the area of control of routing integrity [RFC6480], and key rollover should not cause any transient hiatus in which an RP is led to incorrect conclusions regarding the authenticity of attestations made in the context of the RPKI. A CA cannot assume that all RPs will perform path validation and path discovery in the same fashion; therefore, the key rollover procedure MUST preserve the integrity of the CRL Distribution Points (CRLDP), Subject Information Access (SIA), and Authority Information Access (AIA) pointers in RPKI certificates.
この手順に関するいくつかの考慮事項があり、その後にキーロールオーバー操作を実行するCAが続く必要があります。重要な考慮事項は、RPKIがルーティングの完全性の制御領域に潜在的な応用を持っている[RFC6480]、および主要なロールオーバーは、RPが行われた文脈で行われた認証の信ity性に関する誤った結論に誤った結論に導かれる一時的な休止を引き起こすべきではないことです。RPKI。CAは、すべてのRPSが同じ方法でパス検証とパス発見を実行すると想定することはできません。したがって、主要なロールオーバー手順は、RPKI証明書のCRL分布ポイント（CRLDP）、サブジェクト情報アクセス（SIA）、および権限情報アクセス（AIA）ポインターの整合性を維持する必要があります。
In the procedure described here, the CA creates a "new" CA instance, and has the associated new public key published in the form of a "new" CA certificate. While the "current" and "new" CA instances share a single repository publication point, each CA has its own CRL and its own manifest. Initially, the "new" CA publishes an empty CRL and a manifest that contains a single entry for the CRL. The "current" CA also maintains its published CRL and manifest at this repository publication point.
ここで説明する手順では、CAは「新しい」CAインスタンスを作成し、関連する新しい公開キーを「新しい」CA証明書の形式で公開しています。「現在」と「新しい」CAインスタンスは単一のリポジトリの公開ポイントを共有していますが、各CAには独自のCRLと独自のマニフェストがあります。当初、「新しい」CAは、空のCRLとCRLの単一のエントリを含むマニフェストを公開します。「現在」CAは、このリポジトリの出版ポイントで公開されたCRLとマニフェストを維持しています。
The CA performing key rollover waits for a period of time to afford every RP an opportunity to discover and retrieve this "new" CA certificate, and store it in its local RPKI repository cache instance. This period of time is termed the Staging Period. During this period, the CA will have a "new" CA instance, with no subordinate products, and a "current" CA instance that has issued all subordinate products. At the expiration of the Staging Period, the
CAを実行するキーロールオーバーを実行すると、すべてのRPがこの「新しい」CA証明書を発見して取得し、ローカルRPKIリポジトリキャッシュインスタンスに保存する機会を提供するために一定期間待ちます。この期間はステージング期間と呼ばれます。この期間中、CAには下位製品がない「新しい」CAインスタンスと、すべての下位製品を発行した「現在の」CAインスタンスがあります。ステージング期間の満了時に、
"new" CA instance MUST replace all (valid) subordinate products of the "current" CA instance, overwriting the "current" subordinate products in the CA's repository publication point. When this process is complete, the "current" CA instance is retired, and the "new" CA instance becomes the "current" CA.
「新しい」CAインスタンスは、「現在の」CAインスタンスのすべての（有効な）下位製品を置き換えて、CAのリポジトリ出版ポイントに「現在の」下位製品を上書きする必要があります。このプロセスが完了すると、「現在の」CAインスタンスが廃止され、「新しい」CAインスタンスが「現在の」CAになります。
During the transition of the "current" and "new" CA instances, the "new" CA instance MUST reissue all subordinate products of the "current" CA. The procedure described here requires that, with the exception of manifests and CRLs, the reissued subordinate products be published using the same repository publication point object names, effectively overwriting the old objects with these reissued objects. The intent of this overwriting operation is to ensure that the AIA pointers of subordinate products at lower tiers in the RPKI hierarchy remain correct, and that CA key rollover does not require any associated actions by any subordinate CA.
「現在」および「新しい」CAインスタンスの遷移中、「新しい」CAインスタンスは、「現在」のすべての下位製品を再発行する必要があります。ここで説明する手順では、マニフェストとCRLを除き、再発行された下位製品を同じリポジトリ公開ポイントオブジェクト名を使用して公開し、これらの再発行されたオブジェクトで古いオブジェクトを効果的に上書きすることが必要です。この上書き操作の目的は、RPKI階層の下層層の下位製品のAIAポインターが正しいままであり、CAキーロールオーバーは下位のCAによる関連するアクションを必要としないことを保証することです。
There are three CA states described here:
ここで説明する3つのCA状態があります：
CURRENT: The CURRENT CA is the active CA instance used to accept and process certificate issuance and revocation requests. The starting point for this algorithm is that the key of the CURRENT CA is to be rolled over.
現在：現在のCAは、証明書の発行および取り消し要求を受け入れて処理するために使用されるアクティブなCAインスタンスです。このアルゴリズムの出発点は、現在のCAの鍵はロールオーバーすることであることです。
NEW: The NEW CA is the CA instance that is being created. The NEW CA is not active, and thus does not accept nor process certificate issuance and revocation requests. The NEW CA SHOULD issue a CRL and an EE certificate in association with its manifest to provide a trivial, complete, and consistent instance of a CA.
新しい：新しいCAは、作成されているCAインスタンスです。新しいCAはアクティブではないため、証明書の発行および取り消しリクエストを受け入れたり処理したりしません。新しいCAは、CA.
OLD: The CA instance is in the process of being removed. An OLD CA instance is unable to process any certificate issuance and revocation requests. An OLD CA instance will continue to issue regularly scheduled CRLs and issue an EE certificate as part of the process of updating its manifest to reflect the updated CRL.
古い：CAインスタンスは削除されています。古いCAインスタンスでは、証明書の発行および取り消しリクエストを処理できません。古いCAインスタンスは、定期的にスケジュールされたCRLを発行し続け、更新されたCRLを反映するためにマニフェストを更新するプロセスの一部としてEE証明書を発行します。
To perform a key rollover operation, the CA MUST perform the following steps in the order given here. Unless specified otherwise each step SHOULD be performed without any intervening delay. The process MUST be run through to completion.
キーロールオーバー操作を実行するには、CAはここにある順序で次の手順を実行する必要があります。特に指定されていない限り、各ステップは介入遅延なしで実行する必要があります。プロセスは完了まで実行する必要があります。
1. Generate a new key pair for use by the NEW CA. Because the goal of this algorithm is key rollover, the key pair generated in this step MUST be different from the pair in use by the CURRENT CA.
1. 新しいCAで使用する新しいキーペアを生成します。このアルゴリズムの目標は重要なロールオーバーであるため、このステップで生成されたキーペアは、現在のCAで使用されているペアとは異なる必要があります。
2. Generate a certificate request with this key pair and pass the request to the CA that issued the CURRENT CA certificate. This request MUST include the same SIA extension that is present in the CURRENT CA certificate. This request, when satisfied, will result in the publication of the NEW CA certificate. This (NEW) CA certificate will contain a subject name selected by the issuer, which MUST be distinct from the subject name used in the CURRENT CA certificate. The Certificate Practice Statement (CPS) for the issuer of the NEW CA certificate will indicate the time frame within which a certificate request is expected to be processed.
2. このキーペアで証明書要求を生成し、現在のCA証明書を発行したCAにリクエストを渡します。このリクエストには、現在のCA証明書に存在する同じSIA拡張機能を含める必要があります。このリクエストは、満たされた場合、新しいCA証明書の公開になります。この（新しい）CA証明書には、発行者によって選択された件名が含まれます。これは、現在のCA証明書で使用されている件名とは異なる必要があります。新しいCA証明書の発行者の証明書慣行声明（CPS）は、証明書要求が処理される予定の時間枠を示します。
3. Publish the NEW CA's CRL and manifest.
3. 新しいCAのCRLとマニフェストを公開します。
The steps involved here are:
ここに関連するステップは次のとおりです。
- Wait for the issuer of the NEW CA to publish the NEW CA certificate.
- 新しいCAの発行者が新しいCA証明書を公開するのを待ちます。
- As quickly as possible following the publication of the NEW CA certificate, use the key pair associated with the NEW CA to generate an initially empty CRL, and publish this CRL in the NEW CA's repository publication point. It is RECOMMENDED that the CRL for the NEW CA have a nextUpdate value that will cause the CRL to be replaced at the end of the Staging Period (see in Step 4 below).
- 新しいCA証明書の公開に続いてできるだけ早く、新しいCAに関連付けられたキーペアを使用して、最初に空のCRLを生成し、このCRLを新しいCAのリポジトリ出版ポイントに公開します。新しいCAのCRLには、ステージング期間の終了時にCRLが交換される次の値を持つことをお勧めします（以下のステップ4を参照）。
- Generate a new key pair, and generate an associated EE certificate request with an AIA value of the NEW CA's repository publication point. Pass this EE certificate request to the NEW CA, and use the returned (single-use) EE certificate as the NEW CA's manifest EE certificate.
- 新しいキーペアを生成し、新しいCAのリポジトリ公開ポイントのAIA値で関連付けられたEE証明書要求を生成します。このEE証明書要求を新しいCAに渡し、新しいCAのマニフェストEE証明書として返された（単一使用）EE証明書を使用します。
- Generate a manifest containing the new CA's CRL as the only entry, and sign it with the private key associated with the manifest EE certificate. Publish the manifest at the NEW CA's repository publication point.
- 新しいCAのCRLを唯一のエントリとして含むマニフェストを生成し、マニフェストEE証明書に関連付けられた秘密鍵で署名します。新しいCAのリポジトリ公開ポイントにマニフェストを公開します。
- Destroy the private key associated with the manifest EE certificate.
- マニフェストEE証明書に関連する秘密鍵を破壊します。
4. The NEW CA enters a Staging Period. The duration of the Staging Period is determined by the CA, but it SHOULD be no less than 24 hours. The Staging Period is intended to afford an opportunity for all RPs to download the NEW CA certificate prior to publication of certificates, CRLs, and RPKI signed objects under the NEW CA. During the Staging Period, the NEW CA SHOULD reissue, but not publish, all of the products that
4. 新しいCAはステージング期間に入ります。ステージング期間の期間はCAによって決定されますが、24時間以上かかるはずです。ステージング期間は、すべてのRPSが、新しいCAの下で証明書、CRLS、およびRPKI署名されたオブジェクトを公開する前に、新しいCA証明書をダウンロードする機会を与えることを目的としています。ステージング期間中、新しいCAは再発行する必要がありますが、公開する必要はありません。
were issued under the CURRENT CA. This includes all CA certificates, EE certificates, and RPKI signed objects. Section 4 describes how each reissued product relates to the product that it replaces. During the Staging Period, the CURRENT CA SHOULD continue to accept and process certificate issuance requests and MUST continue to accept and process certificate revocation requests. If any certificates are issued by the CURRENT CA during the Staging Period, they MUST be reissued under the NEW CA during this period. Any certificates that are revoked under the CURRENT CA MUST NOT be reissued under the NEW CA. As noted above, in the case of an emergency key rollover, a CA will decide whether the 24 hour minimal Staging Period interval is appropriate, or if a shorter Staging Period is needed. As the Staging Period imposes no additional burden on Relying Parties, there is no stipulated or recommended maximum Staging Period.
現在のCAの下で発行されました。これには、すべてのCA証明書、EE証明書、およびRPKI署名されたオブジェクトが含まれます。セクション4では、再発行された各製品がそれが置き換える製品にどのように関連しているかについて説明します。ステージング期間中、現在のCAは引き続き証明書の発行要求を受け入れて処理する必要があり、証明書の取り消しリクエストを受け入れて処理する必要があります。ステージング期間中に現在のCAによって証明書が発行された場合、この期間中に新しいCAの下で再発行する必要があります。現在のCAの下で取り消された証明書は、新しいCAの下で再発行されてはなりません。上記のように、緊急キーロールオーバーの場合、CAは24時間の最小ステージング期間間隔が適切かどうか、または短いステージング期間が必要かどうかを決定します。ステージング期間は、頼る当事者に追加の負担を課さないため、規定または推奨される最大ステージング期間はありません。
5. Upon expiration of the Staging Period, the NEW CA MUST publish the signed products that have been reissued under the NEW CA, replacing the corresponding products issued under the CURRENT CA at the NEW CA's repository publication point. This replacement is implied by the file naming requirements imposed by [RFC6481] for these signed products. The trivial manifest for the NEW CA (which contained only one entry, for the NEW CA's CRL) is replaced by a manifest listing all of these reissued, signed products. At this point, the CURRENT CA becomes the OLD CA, and the NEW CA becomes the CURRENT CA. Use the OLD CA to issue a manifest that lists only the OLD CA's CRL. It is anticipated that this step is very brief, perhaps a few minutes in duration, because the CA has reissued all of the signed products during the Staging Period. Nonetheless, it is desirable that the activities performed in this step be viewed as atomic by RPs.
5. ステージング期間が満了すると、新しいCAは、新しいCAの下で再発行された署名済み製品を公開する必要があり、新しいCAのリポジトリ出版ポイントで現在のCAで発行された対応する製品を置き換えなければなりません。この置換は、これらの署名された製品に対して[RFC6481]によって課されるファイルの命名要件によって暗示されています。新しいCAの些細なマニフェスト（新しいCAのCRLの1つのエントリのみを含む）は、これらの再発行されたすべての署名製品をリストするマニフェストに置き換えられます。この時点で、現在のCAは古いCAになり、新しいCAは現在のCAになります。古いCAを使用して、古いCAのCRLのみをリストするマニフェストを発行します。CAがステージング期間中にすべての署名製品を再発行したため、このステップは非常に短い時間で、おそらく数分間であると予想されます。それにもかかわらず、このステップで実行された活動は、RPSによってアトミックと見なされることが望ましいです。
6. Generate a certificate revocation request for the OLD CA certificate and submit it to the issuer of that certificate. When the OLD CA certificate is revoked, the CRL for the OLD CA is removed from the repository, along with the manifest for the OLD CA. The private key for the OLD CA is destroyed.
6. 古いCA証明書の証明書の取り消し要求を生成し、その証明書の発行者に提出します。古いCA証明書が取り消されると、古いCAのCRLがリポジトリから削除され、古いCAのマニフェストが削除されます。古いCAの秘密鍵は破壊されます。
This procedure defines a Staging Period for CAs performing a key rollover operation. This period is defined as a period no shorter than 24 hours.
この手順では、キーロールオーバー操作を実行するCASのステージング期間を定義します。この期間は、24時間以内の期間として定義されます。
RPs who maintain a local cache of the distributed RPKI repository MUST perform a local cache synchronization operation against the distributed RPKI repository at regular intervals of no longer than 24 hours.
分散型RPKIリポジトリのローカルキャッシュを維持しているRPSは、24時間以内の定期的な間隔で、分散型RPKIリポジトリに対してローカルキャッシュ同期操作を実行する必要があります。
This section provides rules a CA MUST use when it reissues subordinate certificates and RPKI signed objects [RFC6488] as part of the key rollover process. Note that CRLs and manifests are not reissued, per se. They are generated for each CA instance. A manifest catalogues the contents of a publication point relative to a CA instance. A CRL lists revoked certificates relative to a CA instance. Key rollover processing for CRLs and manifests is described above, in Section 3.
このセクションでは、主要なロールオーバープロセスの一部として、下位証明書を再発行し、RPKI署名されたオブジェクト[RFC6488]を再発行するときにCAが使用する必要があるルールを提供します。CRLとマニフェストは再発行されないことに注意してください、それ自体。それらは各インスタンスに対して生成されます。マニフェストは、CAインスタンスに対する出版ポイントの内容をカタログ化します。CRLは、CAインスタンスに比べて取り消された証明書をリストします。CRLとマニフェストのキーロールオーバー処理については、上記のセクション3で説明します。
When a CA, as part of the key rollover process, reissues a CA certificate, it copies all of the field and extension values from the old certificate into the new certificate. The only exceptions to this rule are that the notBefore value MAY be set to the current date and time, and the certificate serial number MAY change. Because the reissued CA certificate is issued by a different CA instance, it is not a requirement that the certificate serial number change in the reissued certificate. Nonetheless, the CA MUST ensure that each certificate issued under a specific CA instance (a distinct name and key) contains a unique serial number.
主要なロールオーバープロセスの一部としてCAがCA証明書を再発行すると、古い証明書のすべてのフィールド値と拡張値を新しい証明書にコピーします。この規則の唯一の例外は、以前の値が現在の日付と時刻に設定され、証明書のシリアル番号が変更される可能性があることです。再発行されたCA証明書は別のCAインスタンスによって発行されるため、再発行された証明書の証明書のシリアル番号が変更されることは要件ではありません。それにもかかわらず、CAは、特定のCAインスタンス（明確な名前とキー）に発行された各証明書に一意のシリアル番号が含まれていることを確認する必要があります。
An RPKI signed object is a Cryptographic Message Syntax (CMS) signed-data object, containing an EE certificate and a payload (content) [RFC6488]. When a key rollover occurs, the EE certificate for the RPKI signed object MUST be reissued, under the key of the NEW CA. A CA MAY choose to treat this EE certificate the same way that it deals with CA certificates, i.e., to copy over all fields and extensions, and MAY change only the notBefore date and the serial number. If the CA adopts this approach, then the new EE certificate is inserted into the CMS wrapper, but the signed context remains the same. (If the signing time or binary signing time values in the CMS wrapper are non-null, they MAY be updated to reflect the current time.) Alternatively, the CA MAY elect to generate a new key pair for this EE certificate. If it does so, the object content MUST be resigned under the private key corresponding to the EE certificate. In this case, the EE certificate MUST contain a new public key and a new notBefore value, and it MAY contain a new notAfter value, but all other field and extension values, other than those relating to the
RPKI署名されたオブジェクトは、EE証明書とペイロード（コンテンツ）[RFC6488]を含む暗号化メッセージの構文（CMS）署名されたDATAオブジェクトです。キーロールオーバーが発生した場合、RPKI署名されたオブジェクトのEE証明書は、新しいCAの鍵の下で再発行する必要があります。 CAは、CA証明書を扱うのと同じ方法でこのEE証明書を扱うことを選択できます。つまり、すべてのフィールドと拡張機能をコピーし、その前の日付とシリアル番号のみを変更する場合があります。 CAがこのアプローチを採用している場合、新しいEE証明書がCMSラッパーに挿入されますが、署名されたコンテキストは同じままです。 （CMSラッパーの署名時間またはバイナリの署名時間値が非ヌルの場合、現在の時間を反映するように更新される場合があります。）あるいは、CAはこのEE証明書の新しいキーペアを生成することを選択できます。もしそうなら、EE証明書に対応する秘密鍵の下でオブジェクトコンテンツを辞任する必要があります。この場合、EE証明書には新しい公開キーと新しいNotbeber Valueが含まれている必要があります。また、新しいNotafter値を含む場合がありますが、他のすべてのフィールドおよび拡張値を含む場合があります。
digital signature and its associated certificate validation path, remain unchanged. If the signing time or binary signing time values in the CMS wrapper are non-null, they MAY be updated to reflect the current time.
デジタル署名とそれに関連する証明書検証パスは、変更されていません。CMSラッパーの署名時間またはバイナリの署名時間値が非ヌルの場合、現在の時間を反映するために更新される場合があります。
As noted in Sections 2.1.6.4.3 and 2.1.6.4.4 of [RFC6488], the presence or absence of the signing-time and/or the binary-signing-time attribute MUST NOT affect the validity of the RPKI signed object.
[RFC6488]のセクション2.1.6.4.3および2.1.6.4.4で述べたように、署名時間および/またはバイナリ - 署名時間属性の存在または不在は、RPKI署名されたオブジェクトの妥当性に影響を与えてはなりません。
No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. Infrequent key rollover increases the risk that the rollover procedures will not be followed to the appropriate level of precision, increasing the risk of operational failure of some form in the key rollover process. Regular scheduling of key rollover is generally considered to be a part of a prudent key management practice. However, key rollover does impose additional operational burdens on both the CA and the population of RPs.
キーを永遠に使用する必要はありません。キーが長く使用されているほど、不注意、事故、スパイ、または暗号化によって侵害される可能性が高くなります。まれなキーロールオーバーは、ロールオーバー手順が適切なレベルの精度に従うことができないというリスクを高め、キーロールオーバープロセスで何らかの形の運用障害のリスクを高めます。キーロールオーバーの定期的なスケジューリングは、一般に、慎重なキー管理慣行の一部であると考えられています。ただし、キーロールオーバーは、CAとRPSの母集団の両方に追加の運用負担を課します。
These considerations imply that in choosing lifetimes for the keys it manages, a CA should balance security and operational impact (on RPs). A CA should perform key rollover at regularly scheduled intervals. These intervals should be frequent enough to minimize the risks associated with key compromise (noted above) and to maintain local operational proficiency with respect to the key rollover process. However, key lifetimes should be sufficiently long so that the (system-wide) load associated with key rollover events (across the entire RPKI) does not impose an excessive burden upon the population of RPs. RPs are encouraged to maintain an accurate local cache of the current state of the RPKI, which implies frequent queries to the RPKI repository system to detect changes. When a CA rekeys, it changes many signed objects, thus impacting all RPs.
これらの考慮事項は、管理するキーの寿命を選択する際に、CAはセキュリティと運用上の影響（RPS）のバランスをとる必要があることを意味します。CAは、定期的にスケジュールされた間隔でキーロールオーバーを実行する必要があります。これらの間隔は、主要な妥協に関連するリスク（上記のこと）を最小限に抑え、キーロールオーバープロセスに関してローカルな運用能力を維持するのに十分頻繁に行われる必要があります。ただし、主要な寿命は十分に長く、主要なロールオーバーイベント（RPKI全体）に関連する（システム全体の）負荷がRPSの集団に過度の負担をかけないようにする必要があります。RPSは、RPKIの現在の状態の正確なローカルキャッシュを維持することをお勧めします。これは、RPKIリポジトリシステムの頻繁なクエリを意味して、変更を検出します。CAが再キーになると、多くの署名されたオブジェクトを変更し、すべてのRPSに影響を与えます。
The authors would like to acknowledge the review comments of Tim Bruijnzeels and Sean Turner in preparing this document.
著者は、この文書の準備において、Tim BruijnzeelsとSean Turnerのレビューコメントを認めたいと考えています。
[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、「IPアドレスおよび識別子としてのX.509拡張」、RFC 3779、2004年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。
[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月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、2012年2月。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.
[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「リソース公開キーインフラストラクチャ（RPKI）の署名されたオブジェクトテンプレート」、RFC 6488、2012年2月。
Authors' Addresses
著者のアドレス
Geoff Huston APNIC
Geoff Huston Apnic
EMail: gih@apnic.net
URI: http://www.apnic.net
George Michaelson APNIC
ジョージ・マイケルソン・アペニック
EMail: ggm@apnic.net
URI: http://www.apnic.net
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Stephen Kent BBN Technologies 10 Moulton St. Cambridge、MA 02138 USA
EMail: kent@bbn.com