🙆

RFC 9589: リソース公開鍵基盤(RPKI)の署名済みオブジェクトにおける暗号メッセージ構文(CMS)署名時刻属性の使用について

2024/05/26に公開

RFC

bgp

rpki

tech

要旨

リソース公開鍵基盤(RPKI)では、署名済みオブジェクトは暗号メッセージ構文(CMS)で保護されたコンテンツ・タイプとして定義する。署名済みオブジェクトには、そのオブジェクトが発行者によって署名されたとされる時刻を表す、署名時刻属性が含まれる。RPKIリポジトリには、rsync及びRPKIリポジトリ・デルタ・プロトコルを使用してアクセスできる。これにより、リライング・パーティー(RP)は、検証に使用するRPKIリポジトリのローカル・コピーをリモート・リポジトリと同期できるようになる。本文書では、CMSの署名時刻属性を使用して、異なる同期プロトコルを切り替えた場合のデータの不要な再転送を回避する方法について説明する。本文書は、RFC 6488を更新し、CMS署名時刻属性の存在を義務付け、バイナリ署名時刻属性の使用を禁止する。

本文書の位置付け

本文書は、インターネット標準化過程の文書である。

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

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

著作権表示

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

1. はじめに

リソース公開鍵基盤(RPKI)[RFC6480]では、署名済みオブジェクトは、標準テンプレート[RFC6488]を使用することで暗号メッセージ構文(CMS)[RFC5652] [RFC6268]で保護されたコンテンツ・タイプとして定義される。このテンプレートは、オブジェクトが発行者によって署名された時刻を表す、オプションのCMS署名時刻属性を含む。標準テンプレートが定義された当時は、RPKIリポジトリの唯一の配布メカニズムはrsync だけだった。

標準テンプレートが公開されて以来、RPKIリポジトリの配布のための新たな追加プロトコル「RPKIリポジトリ・デルタ・プロトコル(RRDP)」[RFC8182]が開発された。RPKIリポジトリ運営者はrsyncサービスを提供しなければならないが、RRDPは通常、rsyncと同時に展開され、ほとんどのリライング・パーティー(RP)実装ではデフォルトで優先される。しかし、RPの実装は、RRDPサービスに問題が発生した場合にrsyncへのフォールバックもサポートしている。RRDPの導入経験が増えるにつれて、RPが一方のメカニズムから他方のメカニズムへの切り替えを最適化することの有用性が明らかになってきた。

本文書では、リポジトリ運営者[RFC6481]及びRPが、RRDPからrsyncへの切り替えの負担を最小限に抑えるために、CMS署名時間属性を使用する方法について説明する。さらに、本文書は、CMS署名時刻属性の存在を義務付け、バイナリ署名時間属性の使用を禁止することによって[RFC6488]を更新する。

1.1.要件言語

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」この文書の「」は、ここに示すようにすべて大文字で表示される場合に限り、 BCP 14 [ RFC2119 ] [ RFC8174 ]で説明されているように解釈されます。

2. RRDPからrsyncへの切り替えの最適化

rsyncの連続した同期において、変更されていないファイルの不要な再転送を避けるため、[RPKI-PUB-SERV]は、ファイルにいわゆる「決定論的」(正規化された)タイムスタンプを使用することを推奨する。ファイルの内容が変更されていない場合、リポジトリ運営者は、ファイルの最終変更タイムスタンプも変更されていないことを保証する必要がある(SHOULD )。

本文書は、RRDP経由で以前に取得したデータを活用することで、rsyncの初回使用時に不要な転送も回避する同期戦略を規定することで、前述の概念を前進させる。

執筆時点では、一般的に使用されるすべてのRP実装は、[RPKI-REP-REQS]で説明しているように、最初にRRDPを介した同期を試みる。RRDP経由の同期が何らかの理由で失敗した場合(不正なXML、期限切れのTLS証明書、HTTP接続タイムアウトなど)、RPは代わりにrsync経由の同期を試みる。

rsync同期プロトコルでは、ファイルの最終更新タイムスタンプ(以下「mod-time」)とファイルサイズを、そのファイルに対して汎用のrsync同期アルゴリズムを実行する必要があるかどうかを判断するために使用する。これは、オリジナルのrsync実装[rsync]とOpenBSD実装[openrsync]の両方におけるデフォルト・モードである。ファイルの送信側のコピーと受信側のコピーの両方が同じmod-timeとファイルサイズを持っている場合、ファイルは同じ内容を含んでいるとみなし、転送するファイルのリストから除外する。送信側と受信側の両方でmod-timeに関する一貫性を確保することは、ネットワーク帯域幅、ディスクI/O操作、CPU使用率の面でrsync同期の負担を軽減するのに役立つ。

(RRDP障害後の)rsync同期の負担を軽減するために、リポジトリ運営者とRPは次のガイドラインに従う必要がある(SHOULD)。

2.1. リポジトリ運営者向けのガイダンス

RPKI署名済みオブジェクトをrsync経由で公開するためにファイルシステム階層にシリアル化する場合、署名済みオブジェクトを含むファイルのmod-timeを、署名済みオブジェクトに含まれるCMS署名時刻属性の値に設定する必要がある(SHOULD)。

2.2. リライング・パーティー向けのガイダンス

RRDP経由で取得したRPKI署名済みオブジェクトをファイルシステム階層にシリアル化する場合、署名済みオブジェクトを含むファイルのmod-timeは、署名済みオブジェクトに含まれるCMS署名時刻属性の値に設定する必要がある(SHOULD)。

RPがRRDPを使用してリポジトリのファイルシステム階層を合成する場合、オプションで対応するディレクトリに直接同期することもできる。別の方法として、RPはrsyncの機能「--compare-dest=DIR」を使用して、新しい(空の)ディレクトリに同期することができる。これは、以前のRRDPフェッチによって合成されたファイルシステム階層によって、すでに利用可能なファイルを取得しないようにするためである。DIRコンポーネントには、前にフェッチされ、検証済みのRPKIデータ(ファイルサイズ・パラメータが一致するようにオリジナルのDER符号化形式)が含まれるディレクトリ名を置き換える。

[rsync]のマニュアルページから--compare-dest=DIR:

このオプションはrsyncに対して、転送時に転送先ファイルを比較するための追加階層として、転送先マシンのDIRを使用するよう指示する(転送先ディレクトリにファイルがない場合)。DIRに送信者のファイルと同じファイルが見つかった場合、そのファイルは転送先ディレクトリに転送されない。これは、以前のバックアップから変更されたファイルだけの疎なバックアップを作成するのに便利である。

[openrsync]のマニュアルページから--compare-dest=directory:

宛先マシンでファイルを比較するための代替ベース・ディレクトリとして、ディレクトリを使用する。ディレクトリ内のファイルが送信者のファイルと同一の場合、そのファイルは転送しない。

3. 公開リポジトリにおけるCMS署名時間属性の存在

2022年6月6日から2024年1月29日までに、5つの地域インターネット・レジストリ(RIR)のトラストアンカー(TA)を通じて発見された数百万のRPKI署名済みオブジェクトを含む[rpkiviews]アーカイブを分析したところ、各署名済みオブジェクトにCMS署名時刻属性が含まれていた。

上記は、一般的に使用されるすべてのTAとその下位の認証局(CA)が、CMS署名時刻属性を含む署名済みオブジェクトを生成することを意味する。つまり、CMS署名時刻属性を必須とすることで、既存の一般的なTAまたはCAが準拠しなくなることはないことを意味する。

2024年1月29日現在、署名済みオブジェクトの83.8%について、CMS署名時刻のタイムスタンプがrsyncで観測されたファイルの変更時間と一致している。これは、RPがセクション2.2で概説した戦略を採用した場合、rsyncで必要とされる処理量が大幅に削減されることがすでに判明していることを意味する。

上記の期間中、指定されたリポジトリ内でCMSのバイナリ署名時刻属性[RFC6019]を持つ署名済みオブジェクトは検出されなかった。したがって、CMSのバイナリ署名時刻属性の使用を禁止しても、既存の一般的に使用されているTAまたはCAが準拠しなくなることはない。

4. RFC 6488の更新

このセクションは[RFC6488]を更新し、CMS署名時刻属性を必須とし、CMSバイナリ署名時刻属性の存在を禁止する。

セクション2.1.6.4では、この段落は以下のように置き換えられる。

旧

signedAttrs要素は存在しなければならず(MUST)、コンテント・タイプ属性とメッセージ・ダイジェスト属性[RFC5652]を含まなければならない(MUST)。署名者はまた、署名時間属性[RFC5652]、バイナリ署名時間属性[RFC6019]、または両方の属性を含んでもよい(MAY)。他の署名付き属性を含めてはならない(MUST NOT)。

新

signedAttrs要素は存在しなければならず(MUST)、コンテント・タイプ、メッセージ・ダイジェスト、署名時間属性[RFC5652]を含まなければならない(MUST)。他の署名済み属性を含めてはならない(MUST NOT)。

セクション2.1.6.4.3では、最初の文が以下のように置き換えられる。

旧

署名時属性があってもよい(MAY)。

新

署名時属性がなければならない(MUST)。

セクション2.1.6.4.3の、「署名時属性の有無は、(セクション3で規定されている)署名済みオブジェクトの有効性に影響を及ぼしてはならない(MUST NOT)ことに留意する」という文章を削除する。
セクション2.1.6.4.4は全文削除する。
セクション3の項目1.fを以下のように置き換える。

旧

f. SignerInfo オブジェクトのsignedAttrsフィールドが存在し、コンテント・タイプ属性(OID 1.2.840.113549.1.9.3)とメッセージ・ダイジェスト属性(OID 1.2.840.113549.1.9.4)の両方を含む。

新

f. SignerInfoオブジェクトのsignedAttrsフィールドは、コンテント・タイプ属性(OID 1.2.840.113549.1.9.3)、メッセージ・ダイジェスト属性(OID 1.2.840.113549.1.9.4)、及び署名時刻属性(OID 1.2.840.113549.1.9.5)を含む。

セクション3では、項目1.gを以下のように置き換える。

旧

g. SignerInfo オブジェクトのsignedAttrsフィールドには、コンテント・タイプ属性(OID 1.2.840.113549.1.9.3)、メッセージ・ダイジェスト属性(OID 1.2.840.113549.1.9.4)、署名時間属性(OID 1.2.840.113549.1.9.5)、及びバイナリ署名時間属性(OID 1.2.840.113549.1.9.16.2.46)の4つ以外の属性は含まない。署名時刻属性とバイナリ署名時間属性はあってもよい(MAY)が、必須ではないことに留意する。

新

g. SignerInfoオブジェクトのsignedAttrsフィールドは、コンテント・タイプ属性(OID 1.2.840.113549.1.9.3)、メッセージ・ダイジェスト属性(OID 1.2.840.113549.1.9.4)、及び署名時刻属性(OID 1.2.840.113549.1.9.5)の3つ以外の属性は含まない。

セクション9(参考文献)では、[RFC6019]をリストから削除した。

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

署名時刻属性の正確さに関しては、要件を課していない。これは、署名が生成された時刻に関する信頼できる情報を提供せず、RRDPとrsyncの間のシームレスな切り替えとは無関係である。

[RFC6019]のセキュリティに関する考慮事項では、署名時刻属性とバイナリ署名時刻属性(両方が存在する場合)は同じ日付と時刻を提供しなければならない(MUST)と規定しているが、オブジェクトがこれらの属性に同じ日付と時刻を表さない値をもつ可能性は依然としてある。RPKI署名済みオブジェクト・プロファイルでは、署名時刻を格納するフィールドを1つに制限することで、曖昧さの可能性を排除している。

6. IANA に関する考慮事項

本文書にはIANAのアクションはない。

7. 参考文献

7.1. 引用規格

[openrsync] "openrsync", 2023, <https://www.openrsync.org/>.

[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>.

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.

[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[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>.

[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>.

[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <https://www.rfc-editor.org/info/rfc8182>.

[rsync] "rsync", 2024, <https://rsync.samba.org/>.

7.2. 参考規格

[RFC6019] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 6019, DOI 10.17487/RFC6019, September 2010, <https://www.rfc-editor.org/info/rfc6019>.

[RPKI-PUB-SERV] Bruijnzeels, T., de Kock, T., Hill, F., and T. Harrison, "RPKI Publication Server Best Current Practices", Work in Progress, Internet-Draft, draft-timbru-sidrops-publication-server-bcp-02, 18 January 2024, <https://datatracker.ietf.org/doc/html/draft-timbru-sidrops-publication-server-bcp-02>.

[RPKI-REP-REQS] Bruijnzeels, T., Bush, R., and G. Michaelson, "Resource Public Key Infrastructure (RPKI) Repository Requirements", Work in Progress, Internet-Draft, draft-ietf-sidrops-prefer-rrdp-02, 23 December 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-prefer-rrdp-02>.

[rpkiviews] "rpkiviews", <https://www.rpkiviews.org/>.

謝辞

著者らは、タイ・デ・コック、ニールス・バッカー、ミカエル・アブラハムソン、ラス・ハウズリー、ザヘドゥザマン・サルカー、エリック・ヴィンク、マヘーシュ・ジェタナンダニ、ロマン・ダニリューの有益なレビューに感謝する。

著者のアドレス

ジョブ・スナイデルス
Fastly
アムステルダム
オランダ
メール: job@fastly.com

トム・ハリソン
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
オーストラリア
メール: tomh@apnic.net

更新履歴

2024.5.26

GitHubで編集を提案

要旨