Zenn
📅

RFC 6489: リソース公開鍵基盤(RPKI)での認証局(CA)の鍵ロールオーバー

2024/03/11に公開
Security
RFC
bgp
tech

要旨

本文書は、リソース公開鍵基盤(RPKI)の認証局(CA)がその鍵ペアの計画的なロールオーバーを実行する方法について説明する。また、本文書では、この鍵ロールオーバー手順がリライング・パーティー(RP)に与える影響についても説明する。一般に、RPはRPKIリポジトリに公開されたオブジェクトのローカル・キャッシュを維持することが想定されるため、CAが鍵ロールオーバーを実行する方法は、RPに影響を与える。

本文書の位置付け

本文書は、インターネットのベスト・カレント・プラクティスを文書化したものである。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 5741のセクション2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc6489 で入手できる。

著作権表示

Copyright (c) 2012 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

本文書は、リソース公開鍵基盤(RPKI)[RFC6480]の認証局(CA)が鍵ペアのロールオーバーを実行するために採用するアルゴリズムについて説明する。

本文書は、当該エンティティが鍵ロールオーバーを実行する際に従うべき慎重な手順を定義する。この手順が「慎重」(conservative)な必要があるのは、鍵ロールオーバーにおけるCAの行為が、RPKI分散リポジトリのローカル・キャッシュ・バージョンを維持する上で、リライング・パーティー(RP)の正常な運用を妨げないことを目的としているためである。この手順を使用することで、RPは、[RFC6480]に記載されている検証手順を使用して、RPKI内のすべての真正なオブジェクトを常に検証できるようになる。

1.1. 用語と概念

読者は、「インターネットX.509公開鍵基盤証明書および証明書失効リスト(CRL)プロファイル」[RFC5280]、「IPアドレスおよびAS識別子のX.509拡張」[RFC3779]、「RPKI 証明書のプロファイル」[RFC6487]、「RPKI リポジトリ構造」[RFC6481]に記載されている用語と概念に精通しているものとする。

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119]の記述にしたがって解釈される。

2. CA キーのロールオーバー手順

RPKIにおけるCAとは、CAとエンド・エンティティ(EE)の証明書、および証明書失効リスト(CRL)を発行するエンティティのことである。CAインスタンスは1つの鍵ペア[RFC6487]に関連付けられ、鍵ロールオーバーが定期的にスケジュールされたイベントである場合、時間の経過とともに多くのCAインスタンスが存在することになる。鍵ロールオーバーという文脈での意味合いは、厳密に言えば、CA自体は鍵ロールオーバーを実行しないということである。鍵ロールオーバーと同等の処理を実行するため、CAは自身の「新しい」インスタンスを新しい鍵ペアで作成し、この「新しい」 CAインスタンスを「古い」CAインスタンスの代わりに、RPKI階層の中に効率的に置き換える。

本手順の焦点は、計画された鍵ロールオーバーであり、秘密鍵の漏洩が疑われる、あるいは検出された場合などの緊急の鍵ロールオーバーではないことに留意する。ただし、ここで説明する手順は、「ステージング期間」を除き、緊急の鍵ロールオーバーの状況にも適用できる。

CAが鍵ロールオーバー操作を実行する際に従わなければならない考慮事項がいくつかある。重要な考慮事項は、RPKIはルーティングの完全性の制御[RFC6480]の領域に適用される可能性があり、鍵ロールオーバーによって、RPKIの文脈で行われる認証の真正性に関して、RPが誤った結論を導くような一時的な中断が発生してはならない、ということである。CAは、すべてのRPが同じ方法でパス検証とパス発見を実行すると決めてかかることはできない。したがって、鍵ロールオーバー手順は、RPKI証明書のCRL配布ポイント(CRLDP)、サブジェクト情報アクセス(SIA)、および機関情報アクセス(AIA)ポインタの完全性を維持しなければならない(MUST)。

ここで説明する手順は、CAは「新しい」CAインスタンスを作成し、関連する新しい公開鍵を「新しい」 CA証明書形式で公開する。「現行の」CAインスタンスと「新しい」CAインスタンスは1つのリポジト公開ポイントを共有するが、それぞれのCAは独自のCRLと独自のマニフェストを持つ。「新しい」CAは、最初に空のCRLと、CRLのエントリを1つ含むマニフェストを公開する。「現行」CAも、このリポジトリ公開ポイントにおいて、公開されたCRLとマニフェストを維持する。

鍵ロールオーバーを実行するCAは、すべてのRPがこの「新しい」CA証明書に気付き、取得し、ローカルのRPKIリポジトリ・キャッシュ・インスタンスに格納する機会を与えるために、一定期間待機する。この期間はステージング期間と呼ぶ。この期間中、CAは下位プロダクトを持たない「新しい」CAインスタンスと、すべての下位プロダクトを発行した「現行」CAインスタンスを持つ。ステージング期間の満了時に、「新しい」CAインスタンスは「現行」CAインスタンスの(有効な)すべての下位プロダクトを置き換え、CAのリポジトリ公開ポイントの「現行」下位プロダクトを上書きしなければならない(MUST)。この処理が完了すると、「現行」CAインスタンスを廃棄し、「新しい」CAインスタンスが「現行」CAとなる。

「現行」CAインスタンスと「新しい」CAインスタンスの移行中、「新しい」CAインスタンスは「現行」CAの下位プロダクトをすべて再発行しなければならない(MUST)。ここで説明する手順では、マニフェストとCRLを除いて、再発行された下位プロダクトは同じリポジトリ公開ポイント・オブジェクト名を使用して発行されることが求められる。古いオブジェクトはこれらの再発行されたオブジェクトで上書きする。この上書き操作の目的は、RPKI階層の下位層にある下位プロダクトのAIAポインタが正しい状態を維持し、CAの鍵ロールオーバーが下位CAによる関連アクションを必要としないことを確保することにある。

ここでは、3つのCA状態について説明する。

現行(CURRENT):
現行CAは、証明書の発行および失効要求を受理し、処理するために使用されるアクティブなCAインスタンスである。このアルゴリズムの開始点は、現行のCA鍵がロールオーバーされることである。

新しい(NEW):
新しいCAは、作成されるCAインスタンスである。新しいCAはアクティブではないため、証明書の発行および失効要求を受理することも処理することもない。新しいCAは、CRLおよびEE証明書をそのマニフェストに関連付けて発行し、自明(trivial)で平凡で完全かつ一貫したCAインスタンスを提供する必要がある(SHOULD)。

古い(OLD):
CAインスタンスは削除される過程にある。古いCAインスタンスは、証明書の発行および失効要求を処理できない。古いCAインスタンスは、更新されたCRLを反映するようにマニフェストを更新する処理の一環として、定期的にスケジュールされたCRLを発行し続け、EE証明書を発行する。

鍵ロールオーバーを実行するには、CAはここに示されている順序で以下のステップを実行しなければならない(MUST)。特に指定がない限り、各ステップは遅延を挟むことなく実行する必要がある(SHOULD)。この処理は完了するまで実行しなければならない(MUST)。

  1. 新しいCAが使用する新しい鍵ペアを生成する。 このアルゴリズムの目的は鍵ロールオーバーであるため、このステップで生成される鍵ペアは、現行CAで使われている鍵ペアとは異なるものでなければならない(MUST)。

  2. この鍵ペアで証明書要求を生成し、現行のCA証明書を発行したCAにその要求を渡す。 この要求には、現行のCA証明書に存在するものと同じSIA拡張が含まれていなければならない(MUST)。 この要求が満たされると、新しいCA証明書が発行される。この(新しい)CA証明書には、発行者が選択したサブジェクト名が含まれるが、このサブジェクト名は、現行のCA証明書で使用されているサブジェクト名とは異なるものでなければならない(MUST)。新しいCA証明書の発行者の認証局運用規程(CPS)には、証明書要求が処理されるまでの期間が記載される。

  3. 新しいCAのCRLとマニフェストを公開する。

    ここで必要な手順は次のとおりである。

    • 新しいCAの発行者が新しいCA証明書を公開するのを待つ。

    • 新しいCA証明書の公開後、できるだけ速やかに、新しいCAに関連付けられた鍵ペアを使用して空のCRLを生成し、このCRLを新しいCAのリポジトリ公開ポイントに公開する。新しいCAのCRLには、ステージング期間の終了時にCRLを置き換えるnextUpdate値を設定することが推奨される(RECOMMENDED)(下記のステップ4を参照)。

    • 新しい鍵ペアを生成し、新しいCAのリポジトリ公開ポイントのAIA値を使用して、関連するEE 証明書要求を生成する。このEE証明書要求を新しいCAに渡し、返送された(使い捨ての)EE証明書を新しいCAのマニフェストEE証明書として使用する。

    • 新しいCAのCRLを唯一のエントリとして含むマニフェストを生成し、マニフェストEE証明書に関連付けられた秘密鍵でマニフェストに署名する。新しいCAのリポジトリ公開ポイントでそのマニフェストを公開する。

    • マニフェストEE証明書に関連付けられた秘密鍵を破棄する。

  4. 新しいCAはステージング期間に入る。 ステージング期間はCAによって決定されるが、24時間以上である必要がある(SHOULD)。ステージング期間は、すべてのRPが、新しいCAの証明書、CRL、RPKI署名済みオブジェクトを公開する前に、新しいCAの証明書をダウンロードする機会を提供することを目的としている。ステージング期間中、新しいCAは、現行CAの下で発行されたすべてのプロダクトを再発行する必要があるが、公開はしない。これには、すべてのCA証明書、EE証明書、RPKI署名済みオブジェクトが含まれる。セクション4では、再発行された各プロダクトが、置き換えられたプロダクトとどのように関連するかを説明する。ステージング期間中、現行CAは証明書発行要求の引き続き受理し処理する必要があり(SHOULD)、また証明書失効要求の受理と処理を継続しなければならない(MUST)。ステージング期間中に現行CAが発行した証明書は、この期間中に新しいCAで再発行しなければならない(MUST)。現行CAで失効した証明書は、新しいCAで再発行してはならない(MUST NOT)。上で述べたように、緊急鍵ロールオーバーが発生した場合、CAは最小24時間のステージング期間間隔が適切かどうか、またはより短いステージング期間が必要かどうかを判断する。ステージング期間はリライング・パーティーに追加の負担を課さないため、ステージング期間の上限は規定または推奨されない。

  5. ステージング期間の終了後、新しいCAは、新しいCAの下で再発行された署名済みプロダクトを公開し、新しいCAのリポジトリ公開ポイントで現行CAの下で発行された対応するプロダクトを置き換えなければならない(MUST)。この置き換えは、[RFC6481]がこれらの署名済みプロダクトに課すファイル名の命名要件によって暗黙的に示されている。新しいCAの自明なマニフェスト(新しいCAのCRLのエントリが1つだけ含む)は、再発行されたすべての署名済みプロダクトをすべて列挙するマニフェストに置き換えられる。この時点で、現行CAは古いCAとなり、新しいCAは現行CAとなる。OLD CAを使用して、OLD CAのCRLのみをリストするマニフェストを発行する。CAはステージング期間中にすべての署名済み製品を再発行したため、このステップは非常に短く、おそらく数分で終わると予想される。それにもかかわらず、このステップで実行されるアクティビティはRPによって原子的(基本的)なものと見なされることが望ましい。

  6. OLD CA証明書の失効要求を生成し、その証明書の発行者に提出する。OLD CA証明書が失効すると、OLD CAのCRLが OLD CAのマニフェストとともにリポジトリから削除される。古いCAの秘密鍵は破棄される。

⚠️ RIPEの鍵ロールオーバー

IETF78のRIPEの資料より

① 鍵ロールオーバー前

before-rollover

② フェーズ1

  1. 新しい鍵ペアを生成

  2. 新しい鍵ペアで証明書要求を生成

  3. 新しい証明書の発行とパブリッシュを親に要求

    新しい証明書向けに空のマニフェストとCRLをパブリッシュ

  4. ステージング期間を待つ

phase-1

③ フェーズ2

  1. a) 要求処理を中断、b) 現行CAを旧、新しいCAを保留中にマーク

  2. 保留中のCAを使用して、下位証明書を再発行

  3. 保留中のCAを使用して、下位の署名付きオブジェクトを再発行(マニフェストを除く)

  4. 古いCAのマニフェストを再発行

  5. a) 保留中のCAを現行にマーク、b) 処理を再開

phase-2

④ フェーズ3

  1. 古い鍵の失効要求を生成
  2. 要求実行時に古いCRLとマニフェストを削除

phase-3

(注) RIPEの資料には、新しいCAからTA CAへのAIAポインタの矢印がない

3. リライング・パーティーの要件

本手順では、鍵ロールオーバーを実行するCAのステージング期間を定義する。この期間は、24時間以上の期間として定義される。

分散RPKIリポジトリのローカル・キャッシュを保持するRPは、24時間以内の定期的な間隔で、分散RPKIリポジトリに対してローカル・キャッシュ同期操作を実行しなければならない(MUST)。

4. 証明書とRPKI署名済みオブジェクトの再発行

本セクションは、CAが鍵ロールオーバー処理の一環として下位証明書および RPKI署名済みオブジェクト[RFC6488]を再発行する際に使用しなければならない(MUST)ルールを規定する。CRLとマニフェスト自体は再発行されないことに留意すること。これらはCAインスタンスごとに生成される。マニフェストは、CAインスタンスに関連する公開ポイントのコンテンツを列挙する(catalogues)。CRLには、CAインスタンスに関連して失効した証明書がリストされる。CRLとマニフェストの鍵ロールオーバー処理については、前述のセクション3で説明している。

4.1. CA証明書

CAは、鍵ロールオーバー処理の一環として、CA証明書を再発行する場合、古い証明書のすべてのフィールドと拡張の値を新しい証明書にコピーする。このルールの唯一の例外は、notBefore値が現在の日付と時刻に設定しても良い(MAY)ことと、証明書のシリアル番号が変更しても良い(MAY)ことである。再発行されたCA証明書は別のCAインスタンスによって発行されるため、再発行された証明書のシリアル番号を変更する要件はない。それでも、CAは、特定のCAインスタンス(個別の名前と鍵)で発行された各証明書にユニークなシリアル番号が含まれていることを保証しなければならない(MUST)。

4.2. RPKI署名済みオブジェクト

RPKI署名済みオブジェクトは、EE証明書とペイロード(コンテンツ) [RFC6488]を含む暗号メッセージ構文(CMS)署名済みデータ・オブジェクトである。鍵ロールオーバーが発生した場合、RPKI署名済みオブジェクトのEE証明書は、新しいCAの鍵で再発行しなければならない(MUST)。CAは、このEE証明書を、CA証明書を扱うのと同じ方法、つまり、すべてのフィールドと拡張をコピーする方法で扱う、notBefore日付とシリアル番号のみを変更する方法を選択してもよい(MAY)。CAがこのアプローチを採用する場合、新しいEE証明書がCMSラッパーに挿入されるが、署名されたコンテキストは変わらない。(CMSラッパーの署名時刻またはバイナリ署名時刻の値がnullでない場合、現在時刻を反映するように更新してもよい(MAY)。) あるいは、CAは、このEE証明書用に新しい鍵ペアを生成することを選択してもよい(MAY)。その場合、オブジェクト・コンテンツは、EE証明書に対応する秘密鍵の下で再署名しなければならない(MUST)。この場合、EE証明書には新しい公開鍵と新しいnotBefore値を含めければならず(MUST)、新しいnotAfter値を含めてもよい(MAY)。ただし、デジタル署名とそれに関連する証明書検証パスに関連する値以外のフィールドと拡張の値は、変更されないままである。CMSラッパー内の署名時刻またはバイナリ署名時刻の値がnullでない場合、現在の時刻を反映するように更新してもよい(MAY)。

[RFC6488]のセクション2.1.6.4.3および2.1.6.4.4に記載されているように、signing-time属性および/または binary-signing-time属性の有無は、RPKI署名済みオブジェクトの有効性に影響を与えてはならない(MUST NOT)。

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

どの鍵も永久に使い続けるべきではない。鍵の使用期間が長くなればなるほど、不注意、事故、スパイ行為、暗号解読などによって鍵が漏洩する可能性が高くなる。鍵ロールオーバーの頻度が低いと、ロールオーバーの手順が適切なレベルの正確さで実行されないリスクが増大し、鍵ロールオーバー処理において何らかの形で運用上の障害が発生するリスクが高まる。鍵ロールオーバーの定期的なスケジュールの設定は、一般に、慎重な鍵管理の慣行の一部であると考えられている。しかし、鍵ロールオーバーは、CAとRPの双方に、追加の運用負担がかかる。

これらの考慮事項は、CAが管理する鍵の有効期間を選択する際に、セキュリティと(RPに対する)運用上の影響のバランスを取る必要があることを意味する。CAは、定期的にスケジュールされた間隔で鍵ロールオーバーを実行する必要がある。 これらの間隔は、鍵のセキュリティ侵害(前述のとおり)に関連するリスクを最小限に抑え、鍵ロールオーバー処理に関してローカルの運用熟練度を維持するのに十分な頻度である必要がある。ただし、鍵の有効期間は、(RPKI全体にわたる)鍵ロールオーバー・イベントに伴う(システム全体の)負荷がRPに過度の負担を課さないように、十分に長くする必要がある。RPは、RPKIの現在の状態について正確なローカル・キャッシュを維持することが推奨される。これは、変更を検出するため、RPKIリポジトリ・システムに頻繁に問い合わせることを意味する。CAが鍵の再作成を行う場合、多くの署名済みオブジェクトが変更されるため、すべてのRPに影響を与える。

6. 謝辞

著者らは、この文書を作成するにあたり、ティム・ブリュインゼールとショーン・ターナーのレビューコメントに感謝の意を表する。

7. 参考文献

7.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.

7.2. 参考規格

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.

著者のアドレス

ジェフ・ヒューストン
APNIC
電子メール: gih@apnic.net
URI: http://www.apnic.net

ジョージ・マイケルソン
APNIC
電子メール: ggm@apnic.net
URI: http://www.apnic.net

スティーブン・ケント
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
アメリカ合衆国
メール: kent@bbn.com

変更履歴

  • 2024.3.11
  • 2024.3.13: Errataの追記
  • 2024.4.12: AIA=機関情報アクセス
GitHubで編集を提案

Discussion