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)
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.
この文書では、どのように説明し、リソースの公開鍵インフラストラクチャにおける認証局（CA）（RPKI）は、その鍵ペアの計画ロールオーバーを実行します。この文書はまた、依拠当事者（RPS）のために、このキーロールオーバー手順の影響を指摘しています。一般的には、RPのは、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）の製品です。これは、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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。のセクション4.eで説明したように、コードのコンポーネントは、簡素化された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）の正常な動作を妨害するために意図されていない「保守的」です。この手順を使用して、RPは常時[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アドレスとAS識別子のためのX.509拡張機能」で説明した用語と概念に精通していることを想定しています[ 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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およびエンドエンティティ（EE）証明書および証明書失効リスト（CRL）を発行するエンティティです。 CAのインスタンスは、キーロールオーバーは、定期的にスケジュールされたイベントであれば、その後、時間をかけて、多くのCAインスタンスが存在することを意味している、単一の鍵ペア[RFC6487]に関連しています。キーロールオーバーの文脈における含意は厳密に言えば、CAはそれ自体がキーロールオーバーを実行していない、ということです。キーロールオーバーと同等のものを実行するために、CAは新しいキーペアで、自分自身の「新しい」インスタンスを作成し、効果的に「古い」CAの代わりにRPKI階層にこの「新しい」CAのインスタンスを代入しインスタンス。
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がのコンテキストで作られたアテステーションの信憑性に関する誤った結論に導かれている任意の過渡的な中断が発生することはありませんRPKI。 CAは、すべてのRPが同じ方法でパス検証やパス検出を実行すると仮定することはできません。そのため、キーロールオーバー手順は、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のインスタンスは、「現在の」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.
CURRENT：CURRENT 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.
NEW：NEW CAが作成されているCAのインスタンスです。 NEW CAは、プロセス証明書発行及び失効リクエストも受け付けていませんので、アクティブではない、と。 NEW CAは、CAの、些細な完全な、かつ一貫性のインスタンスを提供するために、そのマニフェストに関連してCRLおよびEE証明書を発行する必要があります
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.
OLD：CAのインスタンスが削除されている過程です。 OLD CAのインスタンスは、任意の証明書発行及び失効要求を処理することができません。 OLD 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. NEW CAが使用する新しい鍵ペアを生成このアルゴリズムの目標は、キーロールオーバーであるため、このステップで生成した鍵のペアは、CURRENT 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証明書の発行になります。この（NEW）CA証明書は、現在のCA証明書で使用されるサブジェクト名は区別していなければなりません発行者により選択されたサブジェクト名を含むであろう。新しいCA証明書の発行者の証明書実施規定（CPS）は、証明書リクエストが処理されることが予想される時間枠を示すことになります。
The steps involved here are:
ここで必要な手順は以下のとおりです。
- Wait for the issuer of the NEW CA to publish the NEW CA certificate.
- NEW 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証明書の公開後、最初に空のCRLを生成し、新しいCAのリポジトリ公開点で、このCRLを公開するための新しいCAに関連付けられた鍵ペアを使用します。 （下記のステップ4で参照）NEW CAのCRLは、ステージング期間の終了時に交換するCRLの原因となりますnextUpdateの値を持つことが推奨されます。
- 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.
- 新しい鍵ペアを生成し、そしてNEW CAのリポジトリ公開ポイントのAIA値に関連したEE証明書要求を生成します。 NEW CAにこのEE証明書要求を渡し、そしてNEW 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証明書に関連付けられた秘密鍵で署名します。 NEW 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 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.
4.新しいCAは、ステージング期間に入ります。ステージング期間の持続時間は、CAによって決定され、それは24時間以上であってはなりません。ステージング期間は、前の証明書の公表にCRLを新しいCA証明書をダウンロードするには、すべてのRPのための機会を与えることを意図し、そしてRPKIはNEW CAの下のオブジェクトに署名していますステージング期間中、NEW CAは再発行する必要がありますが、、CURRENT、CAの下で発行された製品のすべてを公開していませんこれは、すべてのCA証明書、EE証明書が含まれており、RPKIは、オブジェクトに署名しました。第4節では、それぞれの再発行製品が代わる製品とどのように関係するかを説明します。ステージング期間中に、CURRENT CAは受け入れ続け、プロセス証明書発行要求と証明書の失効要求を受け入れて処理し続けなければならないべきです。いずれかの証明書がステージング期間中CURRENT CAによって発行された場合は、この期間中に、新しいCAの下に再発行されなければなりません。 CURRENT CAの下で取り消されたすべての証明書は、NEW、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.ステージング期間の満了時には、NEW CAはNEW CAのリポジトリの公開時点でのCURRENT CAの下で発行され、対応する製品を置き換える、NEW CAの下で再発行されている署名の製品を公開する必要があります。この置換は、これらの署名の製品のために[RFC6481]によって課された要件を命名ファイルによって暗示されます。 （NEW CAのCRLのための唯一つのエントリを、含まれている）NEW CAのための些細なマニフェストは、これらの再発行、署名した製品のすべてを一覧表示するマニフェストに置き換えられます。この時点で、CURRENT CAはOLD CAになり、NEW CAはCURRENT CA.なり唯一OLD CAのCRLを表示する目録を発行するOLD CAを使用してください。 CAがステージング期間中に署名した製品のすべてを再発行しているので、このステップは、期間中に、おそらく数分、非常に簡単であることが予想されます。それにもかかわらず、この工程で行う活動はのRPによって原子と見なすことが望ましいです。
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. OLD CA証明書の証明書失効要求を生成し、その証明書の発行者に提出してください。 OLD CA証明書が取り消されたときに、OLD CAのCRLは、OLD CAのマニフェストと共に、リポジトリから削除されますOLD 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.
この手順では、キーロールオーバー操作を実行するCAのステージング期間を定義します。この期間は、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リポジトリのローカルキャッシュを維持RPは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のインスタンスのために生成されます。マニフェストは、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証明書を再発行する場合、古い証明書からコピーフィールドおよび拡張の値のすべてを新しい証明書に。この規則の唯一の例外は、notBeforeの値が現在の日付と時刻に設定されるかもしれない、と証明書のシリアル番号が変更される可能性があることです。再発行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 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.
RPKI署名されたオブジェクトは、EE証明書及びペイロード（コンテンツ）[RFC6488]を含む、暗号メッセージ構文（CMS）署名されたデータオブジェクトです。キーロールオーバが発生すると、RPKI署名されたオブジェクトのEE証明書は、新しいCAのキーの下で、再発行しなければなりませんCAは、このEE証明書に、それはすべてのフィールドと機能拡張をコピーするためにCA証明書、すなわち、を扱うのと同じ方法を扱うのを選ぶかもしれ、とだけnotBeforeの日付とシリアル番号を変更することがあります。 CAは、このアプローチを採用している場合、新しいEE証明書は、CMSラッパーに挿入されますが、署名したコンテキストは同じまま。 （CMSラッパーで署名時間またはバイナリ署名時刻の値がnullである場合、それらは、現在の時刻を反映するために更新されることがあります。）また、CAは、このEE証明書の新しい鍵ペアを生成するために選ぶことができます。それはそうする場合は、オブジェクトの内容は、EE証明書に対応する秘密鍵の下で辞任しなければなりません。この場合には、EE証明書は、新しい公開鍵と新しいnotBeforeの値を含まなければなりません、そして、それは、デジタル署名及びそれに関連する証明書検証パスに関連するもの以外の新しいnotAfterの値が、他のすべてのフィールドと拡張値を含んでいてもよいです、変更されません。 CMSラッパーで署名時間またはバイナリ署名時刻の値がnullである場合、それらは、現在の時刻を反映するために更新されてもよいです。
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とのRPの人口の両方に追加の運用負担を課します。
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間）キーロールオーバーイベントに関連付けられている（システム全体の）負荷がのRPの集団に過度な負担を課さないように、しかし、キーの有効期間が十分に長くする必要があります。 RPは、変化を検出するためにRPKIリポジトリシステムに頻繁に照会を意味RPKI、現在の状態の正確なローカルキャッシュを維持することが奨励されます。 CAのキー更新が、それは多くの署名のオブジェクトを変更すると、したがって、すべてのRPに影響を与えます。
The authors would like to acknowledge the review comments of Tim Bruijnzeels and Sean Turner in preparing this document.
著者は、この文書を作成するにはティム・Bruijnzeelsとショーン・ターナーのレビューコメントを確認したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]リン、C.、ケント、S.、およびK.ソ、 "IPアドレスとAS識別子のためのX.509拡張機能"、RFC 3779、2004年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M.とS.ケント、 "安全なインターネットルーティングをサポートするインフラストラクチャ"、RFC 6480、2012年2月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481]ヒューストン、G.、Loomans、R.、およびG.マイケルソン、 "リソース証明書リポジトリの構造用プロフィール"、RFC 6481、2012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487]ヒューストン、G.、マイケルソン、G.、およびR. Loomans、 "X.509 PKIXリソース証明書のプロファイル"、RFC 6487、2012年2月。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.
[RFC6488] Lepinski、M.、チー、A.、およびS.ケントは、RFC 6488、2012年2月 "リソースの公開鍵インフラストラクチャ（RPKI）のためのオブジェクト・テンプレートを署名"。
Authors' Addresses
著者のアドレス
Geoff Huston APNIC
ジェフ・ヒューストンAPNIC
EMail: gih@apnic.net URI: http://www.apnic.net
電子メール：gih@apnic.net URI：http://www.apnic.net
George Michaelson APNIC
ジョージ・マイケルソンAPNIC
EMail: ggm@apnic.net URI: http://www.apnic.net
電子メール：ggm@apnic.net URI：http://www.apnic.net
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
スティーブン・ケントBBNテクノロジーズ10モールトンセントケンブリッジ、MA 02138 USA
EMail: kent@bbn.com
メールアドレス：kent@bbn.com