💾

RFC 6481: リソース証明書リポジトリ構造のプロファイル

2024/02/16に公開

RFC

bgp

tech

要旨

本文書は、リソース公開鍵基盤(RPKI)の分散リポジトリの構造に関するプロファイルを定義する。個々のリポジトリ公開ポイントは、X.509/PKIXリソース証明書、証明書失効リスト、および署名済みオブジェクトに対応するファイルを格納するディレクトリである。このプロファイルは、オブジェクト(ファイル)の命名スキーム、リポジトリ公開ポイント(ディレクトリ)の内容、およびローカル・リポジトリ・キャッシュの推奨内部構造を定義するものであり、リポジトリ公開ポイントの分散コレクション間の同期を容易にし、証明書パスの構築を手助けすることを目的としている。

本文書の位置付け

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

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

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

著作権表示

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

1. はじめに

リソース公開鍵基盤(RPKI)[RFC6480]の文脈で作成された証明書を検証するため、リライング・パーティー(RP)は、RPKIをトータルで定義するすべてのX.509/PKIXリソース証明書、証明書失効リスト(CRL)、および署名済みオブジェクトにアクセスする必要がある。

証明書、CRL、あるいは署名済みオブジェクトの各発行者は、オブジェクトをRPKIリポジトリに公開することで、RPがダウンロード可能になる。

リポジトリ・システムは、すべてのRPがグローバルにアクセス可能でなければならない(MUST)、すべての署名済みオブジェクトのコレクションである。証明書、CRL、署名済みオブジェクトが作成されると、リポジトリ公開ポイントにアップロードされ、そこからRPで使用するためにダウンロードできる。

このプロファイルは、推奨されるオブジェクト(ファイル)の命名スキーム、推奨されるリポジトリ公開ポイント(ディレクトリ)の内容、およびローカル・リポジトリ・キャッシュの推奨される内部構造を定義するもので、リポジトリ公開ポイントの分散コレクション間の同期を容易にし、証明書パスの構築を手助けすることを目的としている。

リソース証明書は、エンティティの公開鍵とIPアドレス・ブロックおよびAS番号との結び付きを証明する。リソース証明書のサブジェクト(対象者)は、秘密鍵を使用してデジタル署名(証明書の公開鍵を使用して検証可能)を生成することで、証明書に列挙されたリソースの保有者であることを証明できる。

1.1. 用語

読者は、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile」(インターネットX.509公開鍵基盤証明書および証明書失効リスト(CRL)のプロファイル)[RFC5280]および「X.509 Extensions for IP Addresses and AS Identifiers」(IPアドレスおよびAS識別子のX.509拡張)[RFC3779]に記載されている用語と概念に精通していることを前提とする。

さらに、本文書では以下の用語を使用する。

リポジトリ・オブジェクト(またはオブジェクト):
リポジトリ公開ポイント内のターミナル・オブジェクトを指す。ターミナル・オブジェクトとは、公開でアクセス可能なディレクトリ内のファイルとして実装されるのが通例である。ファイルはディレクトリそのものではないが、ファイルと同様の公開外観を持つ別の形のオブジェクトもこの用語に含まれる。

リポジトリ公開ポイント:
これは、共通の公開ポイントで公開されるリポジトリ・オブジェクトのコレクションを指す。これは慣例的に、URI[RFC3986]で識別される、公開でアクセス可能なファイルシステム内のディレクトリとして実装されていたが、ファイルの単純なディレクトリに類似した公的外観を持つ別の形のローカル・ストレージもこの用語に含まれる。

リポジトリ・インスタンス:
共通の公開インスタンスを共有する1つ以上のリポジトリ公開ポイントのコレクションを指す。これは慣例的に、共通のURIプレフィックスを共有するファイルシステム・ディレクトリのコレクションとして実装され、各ディレクトリは独自のユニークなURIでも識別可能である。

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

2. RPKIリポジトリ公開ポイントの内容と構造

RPKIでは、1つのリポジトリ・インスタンスに公開されたすべてのRPKIオブジェクトを格納する必要はない。それどころか、RPKIリポジトリ・システムは複数のリポジトリ・インスタンスで構成される。個々のリポジトリ・インスタンスは、1つ以上のリポジトリ公開ポイントで構成される。各リポジトリ公開ポイントは、証明書のサブジェクト情報アクセス(SIA)拡張に定義されているように、RPKI証明書で参照される1つ以上のエンティティによって使用される。

このセクションでは、リポジトリ公開ポイントに格納されるオブジェクト(RPKI証明書、CRL、マニフェスト、署名済みオブジェクト)のコレクションについて説明する。

RPKI内のすべての認証局(CA)証明書に対して、対応するリポジトリ公開ポイントが存在し、このリポジトリ公開ポイントは、このCAが発行した現在のすべての証明書および CRLの正式な公開ポイントである。証明書のSIA拡張には、このリポジトリ公開ポイントを参照するURI[RFC3986] が含まれ、リポジトリへのアクセス方法を特定する。さらに、証明書の機関情報アクセス(AIA)拡張には、特定の証明書が発行されたCA証明書の正式な場所を参照するURIが含まれる。

例えば、証明書Aのサブジェクト(対象者)が証明書BとCを発行している場合、証明書BとCのAIA拡張は共に証明書Aオブジェクトの公開ポイントを指し、証明書AのSIA拡張は、証明書BとCを含むリポジトリ公開ポイント(ディレクトリ)を指す(図1参照)。

fig1
図1. RPKIにおけるAIAおよびSIA拡張の使用

図1では、証明書BとCは、CA Aが発行している。したがって、証明書BとCのAIA拡張は(証明書)Aを指し、証明書AのSIA拡張はCA Aの下位のリポジトリ公開ポイントを指す。ここには、証明書BとC、およびAが発行したCRLも含まれる。証明書BとCのCRL配布ポイント(CRLDP)拡張は、いずれもAが発行したCRLを指す。

この分散リポジトリ構造において、CAのリポジトリ公開ポイントのインスタンスには、そのCAが発行したすべての公開証明書と、そのCAが発行したCRLが含まれる。このリポジトリには、このCAが発行したエンド・エンティティ(EE)証明書によって検証される、公開されたすべてのデジタル署名オブジェクトも含まれる。

2.1. マニフェスト

すべてのリポジトリ公開ポイントは、マニフェスト[RFC6486]を含まれなければならない(MUST)。マニフェストには、CAまたはEEによって現在公開されているすべてのオブジェクトの名前と、各オブジェクトのコンテンツのハッシュ値のリストが含まれる。

オーソリティは、リポジトリ変更の範囲内のすべての操作をカバーする1つのマニフェストを発行する前に、この変更の範囲内で公開リポジトリに対して多数のオブジェクト操作を実行してもよい(MAY)。リポジトリ・オペレータは、リポジトリおよび関連するマニフェストの変更中に、リポジトリ上で取得操作を行っているRPが中間状態にさらされないことを確実にするため、何らかの形のディレクトリ管理体制機能をリポジトリ上に実装する必要がある(SHOULD)。(そのようなアクセス体制が整備されていない場合、RPはマニフェストとリポジトリの内容が正確に一致しない中間リポジトリ状態にさらされる(MAY)ことに留意する。このようなマニフェストとリポジトリの内容が一致しない状況における具体的なケースとアクションは、[RFC6486]で検討されている。)

2.2. CAリポジトリ公開ポイント

CA証明書は、そのSIAフィールドに指定される2つのaccessMethod要素を持つ。id-ad-caRepository accessMethod要素は、[RFC6487]で規定しているように、このCAが発行する証明書のリポジトリ公開ポイントを指す、関連するaccessLocation要素を持つ。id-ad-rpkiManifest accessMethod要素は、(ディレクトリURIとは異なる)オブジェクトURIとして、このCAに関連するマニフェスト・オブジェクトを指す、関連するaccessLocation要素を持つ。

CAの公開リポジトリには、このCAが発行した現在の(期限切れおよび失効していない)証明書、このCAが発行した最新のCRL、現在のマニフェスト、およびこのCAが発行したEE証明書[RFC6487]を使用して検証できる他の現在のすべての署名済みオブジェクトが含まれる。

CAのマニフェストには、マニフェスト自体を唯一の例外として、各オブジェクトの内容のハッシュ値と共に、このオブジェクトのコレクションの名前が含まれる。

RPKIの設計では、CAが1つの鍵ペアに一意に関連付けることが必要である。したがって、CAである管理エンティティは、新しいサブジェクト名を持つ新しいCA証明書と新しい鍵ペアを生成することによって、鍵のロールオーバーを実行する[RFC6489]。(新しいサブジェクト名を使用する理由は、RPKIの文脈において、CAが発行するすべての証明書のサブジェクト名は一意であることが意図されており、RPKIの鍵ロールオーバー手順により、新しい鍵を持つCAの新しいインスタンスが作成されるため、名前制約により、新しい鍵を持つCAの新しいサブジェクト名が必要となるためである。)このような場合、エンティティは、鍵のロールオーバーの間、両CAインスタンスについて同じリポジトリ公開ポイントを使用し続け、このCAが発行した証明書を参照する間接従属オブジェクト内のAIA拡張の値が、鍵ロールオーバー後も有効であり続けること、そして鍵ロールオーバーにおける下位証明書の再発行がこのCAの直属の下位のコレクションに限定されることを保証する必要がある[RFC6489]。このような場合、リポジトリ公開ポイントには、両CAインスタンスのCRL、マニフェスト、および下位証明書が含まれる。(エンティティが新旧のCA鍵に別々のリポジトリ公開ポイントを使用することは可能だが、その場合、RPKI階層の間接的な下位レベルのAIAポインタが新CAの下位に正しく調整されるよう、下位のCAおよびEEと非常に慎重な調整が必要となる。)

次の段落では、CAのリポジトリ公開ポイントにおけるオブジェクトの命名に関するガイドラインである:

CRL:
CAが新しいCRLを発行する場合、(同じCA鍵ペアの下で発行された)以前のCRLをリポジトリ公開ポイントで置き換える。CAは、リポジトリ公開ポイントで以前のCRLを公開し続けてはならない(MUST NOT)。したがって、同じCA(インスタンス)によって署名された以前のCRLを置き換え(上書き)なければならない(MUST)。このようなオブジェクトの命名に関する非・規範的なガイドラインとして、リポジトリ内のCRLに選択されるファイル名は、CAの公開鍵に由来する値を選択する。CRL公開名を生成するこのような方法の1つは、[RFC4387]のセクション2.1に記載されている。CAの公開鍵値の160ビットハッシュを、[RFC4648]のセクション5、表2で提案されている追加変更を加えたBase64符号化の修正形式を使用して、27文字の文字列に変換する。ファイル名拡張子「.crl」は、ファイルがCRLであることを示すために使用しなければならない(MUST)。各「.crl」ファイルには、DER形式で符号化されたCRLが正確に1つだけ含まれる。

マニフェスト:
マニフェストの新しいインスタンスが公開される場合、混乱を避けるため、以前のマニフェストを置き換えなければならない(MUST)。CAは、リポジトリ公開ポイントにおいて以前のCAマニフェストを公開し続けてはならない(MUST NOT)。オブジェクトの命名に関する非・規範的ガイドラインでは、公開リポジトリのマニフェストに選ばれるファイル名について、上記のCRLで説明したアルゴリズムを使用して、エンティティの鍵ペアの公開鍵部分から導出した値とする。ファイル名の拡張子「.mft」は、オブジェクトをマニフェストとして示すために使用しなければならない(MUST)。

証明書:
RPKIフレームワークにおいて、CAは、同じサブジェクト名、同じサブジェクト公開鍵、同じリソース・コレクションに対して、証明書シリーズを発行することができる。ただし、リライング・パーティーは、このような証明書シリーズのうち、最も最近発行された証明書のみにアクセスする必要がある。したがって、このような証明書シリーズは、同じファイル名を共有する必要がある(SHOULD)。これにより、このような一連の連続して発行される証明書は、証明書のインスタンスを効果的に上書きする。異なるファイル名を使用することも可能だが、検証するユーザに負担がかかる。このようなオブジェクトの命名に関する非・規範的ガイドラインとして、CAは、同じサブジェクトに対して発行される証明書シリーズの一意のインスタンスごとに、一意の鍵ペアを使用することをサブジェクトに要求する(ローカルな)ポリシーを採用し、これにより、CAは、サブジェクトの公開鍵に基づくファイル名生成スキーム、例えば、上記のCRLについて説明したアルゴリズムを使用することができる。公開された証明書は、オブジェクトを証明書として示すために「.cer」のファイル名拡張子を使用しなければならない(MUST)。各「.cer」ファイルには、DER形式で符号化された証明書が1つだけ含まれる。

⚠️ ファイル名について

要するに、CERもCRLもマニフェストもファイル名は同じということ。

$ find . -name 'qggJfGBgcQKAzaqk5-BsHxPNFvI*' -print
./qggJfGBgcQKAzaqk5-BsHxPNFvI.cer
./897/qggJfGBgcQKAzaqk5-BsHxPNFvI.crl
./897/qggJfGBgcQKAzaqk5-BsHxPNFvI.mft
$ ls 897
1pAPHjEm5gnvTxoPuFXrTeTjoYo.crl  PMHXRV65WPOUKJ4eDXiNyktBHe8.roa
1pAPHjEm5gnvTxoPuFXrTeTjoYo.mft  qggJfGBgcQKAzaqk5-BsHxPNFvI.crl
9cPt2jlzH4Hy7uCX-AOEHj97EbU.roa  qggJfGBgcQKAzaqk5-BsHxPNFvI.mft
A-PQaIy7Aj6SGglUStmFTzDNdBA.roa  Tp3k5cYM4FQUch4cvRbP4mcFzk4.roa
DihJrjs9GlSeaVjK1tnC9Q3qubI.roa  uzSme_hzcVcjNMhkTZ2Znr-3lPE.roa
EG0bDhLVWIojsD-7IA1ZEFdL7RM.roa  vZ0_f9ofcDD8moM9jyOUtzekmhI.roa
gAjzM-YWurv55eYXEnxhmIg-aoM.roa  yGq5lVRWyGmJp9nZCJJwq-rBikE.roa
mQqczKKp9AcivFIXapJFTgQc5AY.roa  ZFTGe6JXlPw7YSB8OEOXnj-FCz0.roa
O4BUOWqXuLmJ0wiSTUlFl2w9fLg.roa

署名済みオブジェクト:
RPKI署名済みオブジェクト[RFC6488]は、署名済みオブジェクトのデジタル署名を検証するために使われるEE証明書を発行したCA証明書のSIAが参照するリポジトリ公開ポイントに公開される(そのEE証明書のSIAによって直接参照される)。このようなRPKI署名オブジェクトの命名に関する一般的な非・規範的ガイドラインは、このようなオブジェクトのファイル名は、上述のアルゴリズムを適用して、関連するEE証明書の公開鍵から導出するというものである。公開されたRPKI署名済みオブジェクトでは、ファイル名の拡張子「.crl」、「.mft」、または「.cer」を使用してはならない(MUST NOT)。

この文書の公開時点で定義されている署名済みオブジェクトの1つの形式は、経路発信認可(ROA)[RFC6482]である。公開されたROAは、オブジェクトがROAであることを示すために、「.roa」のファイル名拡張子を使用しなければならない(MUST)。

3. リソース証明書公開リポジトリの考慮事項

各発行者は、発行した証明書とCRLを任意のリポジトリで公開してもよい(MAY)。ただし、適切なリポジトリ公開構造の選択の指針となる考慮事項が多数ある。

公開リポジトリは、可用性の高いサービスと大容量の公開プラットフォームへホスティングする必要がある(SHOULD)。
公開リポジトリは、rsync[RFC5781] [RSYNC]が利用可能でなければならない(MUST)。追加の取得メカニズムのサポートは、リポジトリ・オペレータの選択とする。サポートされる取得メカニズムは、関連するCAまたはEE証明書のSIAで指定されたaccessMethod要素の値と一致しなければならない(MUST)。
各CAのリポジトリ公開ポイントには、このCAが発行したEE証明書によって検証できるオブジェクトを含む、このCAのプロダクトを含む必要がある(SHOULD)。同じエンティティによって運営されている関連CAの署名済みプロダクトは、このCAリポジトリ公開ポイントを共有してもよい(MAY)。サブディレクトリを除き、その他のオブジェクトは、リポジトリ公開ポイントに配置してはならない(SHOULD NOT)。

このようなサブディレクトリは、CAディレクトリに含まれるCAまたはEE証明書のリポジトリ公開ポイントである必要がある(SHOULD)。これらの考慮事項は、これらのディレクトリのサブディレクトリにも再帰的に適用される。CAのプロダクトではないコンテンツの検出は、RPを混乱させる可能性があり、このような場合、RPはCAのリポジトリ公開ポイントにある有効なCAプロダクトを無効にしないように注意する必要がある。
署名済みオブジェクトは、各オブジェクトの署名を検証するために使用されるEE証明書のSIAフィールドが示す場所で公開される。署名済みオブジェクトは、EE証明書を発行したCA証明書のリポジトリ公開ポイントに公開される。EE証明書の SIA拡張は、リポジトリ公開ディレクトリではなく、このオブジェクトを参照する[RFC6487]。
セクション2.1では、リポジトリ・オペレータは、リポジトリ上で取得操作を実行しているRPが、リポジトリと関連するマニフェストの変更中に中間状態にさらされないようことを保証するため、リポジトリ上で何らかの形のディレクトリ管理体制機能を実装する必要がある(SHOULD)と述べている。以下の解説にもかかわらず、RPは一貫したリポジトリとマニフェストの状態が保証されると仮定すべきではなく、それに従って取得操作を体系化すべきである(セクション5参照)。

マニフェストとディレクトリの内容が矛盾するリスクを軽減するディレクトリ更新体制を、リポジトリ・オペレータがどのように実装するかは、リポジトリをホスティングするファイルシステムの運用特性に依存するため、以下のコメントはリポジトリ・オペレータに対する暗黙のガイドラインという点で規範的なものではない。

大規模なディレクトリの更新中に一貫性のない取得状態にさらされるのを避けるために、一般的に使われる手法は、行うべき一連の変更をバッチ処理し、ディレクトリの内容のワーキングコピーを作成してから、ディレクトリのローカルコピーに対して変更のバッチを実行することである。完了したら、リポジトリ・ディレクトリ名のファイルシステムのシンボリック・リンクの名前を、このワーキングコピーのディレクトリを指すように変更する。古いリポジトリ・ディレクトリの内容は、少し後で削除できる。しかし、ディレクトリ上で実行されるクライアント同期機能の完全性を保証するという点で、この手法の成果は、サポートされているアクセス・メカニズムとローカル・ファイルシステムの動作との相互作用に依存することに留意すること。おそらく、この手法で、マニフェストとリポジトリ間でRPが矛盾した状態を認識する可能性をすべて排除することはできない。なぜなら、リポジトリは部分的に更新された状態になる可能性があり、常に内部的に一貫性があることを保証できないからである。

4. 証明書の再発行とリポジトリ

CA証明書が再発行される場合(例えば、番号リソース拡張に含まれるリソース・セットの変更など)、その証明書に基づいて発行されたすべての証明書を再発行する必要はない。これらの証明書には、CA証明書の公開ポイントを指すAIA拡張が含まれるため、CAは、証明書の再発行イベント全体にわたって持続するリポジトリ公開ポイントの名前を使用する必要がある(SHOULD)。つまり、再発行されたCA証明書は、同じサブジェクトおよびサブジェクト公開鍵を持つ以前に発行されたCA証明書と同じリポジトリ公開ポイントを使用する必要があり(SHOULD)、そのような証明書の再発行は、リポジトリ公開ポイント内で以前に発行された証明書を意図的に上書きする必要がある(SHOULD)。

セクション2.2では、CAが鍵ロールオーバーを実行する場合、エンティティは鍵ロールオーバー後も存続するリポジトリ公開ポイントの名前を使用する必要がある(SHOULD)と述べている。このような場合、リポジトリ公開ポイントには、鍵ロールオーバー手順における一時的な状態として、両方のCAインスタンスのCRLとマニフェストが含まれる。RPKIの鍵ロールオーバー手順[RFC6489]では、共通リポジトリ公開ポイントにおいて、旧CAの下位プロダクトが、新CAが発行した下位プロダクトによって上書きされることが求められる。

5. リポジトリとローカル・キャッシュの同期

AIA、SIA、CRLDP証明書フィールドに基づき、個々の証明書、候補証明書セット、および証明書失効リストをオンラインで取得することにより、証明書パス構築の検証関連タスクを実行することができる。これは、速度と効率が重要な考慮事項である場合には推奨されない(NOT RECOMMENDED)。

RPKI証明書、CRL、および署名済みオブジェクトの効率的な検証を可能にするため、各リライング・パーティーは、すべての有効な証明書、現在の証明書失効リスト、および関連するすべての署名済みオブジェクトの同期コピーを含むローカル・リポジトリを維持することが推奨される。

リポジトリ同期の一般的なアプローチは、分散リポジトリ構造を「トップダウン」で散策することである。これは、ローカルで選択されたトラストアンカーに対応する、ローカルで選択されたトラストアンカー資料の収集から始まり、このプロセスの「シード」となる自己署名リソース証明書の初期セットを読み込むために使用できる [RFC6490]。次に、このプロセスは、ローカル・リポジトリのキャッシュに、発行者によって発行されたすべての有効な証明書を追加する。この手順は、下位の証明書に再帰的に適用できる。このようなリポジトリ・トラバーサル・プロセスは、最初のトラストアンカーからローカルに設定された最大チェーン長をサポートする必要がある(SHOULD)。これを行わないと、SIAポインタのループや他の論理的なRPKI階層の縮退形が発生し、RPのローカルRPKIキャッシュとリポジトリの同期操作を実行する際に、RPが誤動作する可能性がある。

RPは、このローカル同期で取得したマニフェスト[RFC6486]を使用し、各リポジトリ公開ポイントの現在の一貫した状態に対して同期を保証する必要がある(SHOULD)。セクション3では、リポジトリ公開ポイントの内容が更新されたとき、リポジトリ・オペレータはマニフェストの内容とリポジトリの内容が常に正確に一致することをRPに保証できないことに指摘している。RPは、この一時的な不整合の可能性を考慮した取得アルゴリズムを使用する必要がある(SHOULD)。RPがこの状況を軽減するために考えられるアルゴリズムとしては、リポジトリ全体の同期を2 回連続して実行すること、あるいはディレクトリの内容の同期の前後でマニフェストの取得を実行し、マニフェストの2番目のコピーが最初のコピーと異なる場合に同期機能を繰り返すことなどが挙げられる。

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

リポジトリは完全性が保護されたデータベースであるとは想定されていないため、リポジトリの取得操作はさまざまな形の「中間者」攻撃に対して脆弱になる可能性がある。取得されたオブジェクトの破損は、取得された各オブジェクトに関連付けられた署名の検証を通じて、リライング・パーティーによって検出可能である。オブジェクトの新しいインスタンスが同じオブジェクトの古いインスタンスに置き換えられても、マニフェストを使用することで検出できる。失効し、削除された証明書の挿入は、スケジュールされた間隔でCRLを取得し、処理することで検出できる。しかし、マニフェストとCRLを使用しても、リライング・パーティーは、古い(失効していない)有効なオブジェクトに基づくあらゆる形態の置換攻撃を検出できるわけではない。

機密性は、リポジトリやリポジトリで公開される署名済みオブジェクトでは提供しない。署名済みオブジェクトに含まれるデータの機密性を保証するために使用される何らかの指定されたメカニズムがない限り、アクセス制御の対象となるデータをリポジトリの署名済みオブジェクトに含めるべきではない。

7. IANA に関する考慮事項

7.1. メディアの種類

IANAは次の2つのメディアタイプを登録している。

application/rpki-manifest
application/rpki-roa

この文書では、[RFC2585]で定義されているapplication/pkix-certおよびapplication/pkix-crlのメディア登録の.cerと.crlファイル拡張子も使用する。

7.1.1. application/rpki-manifest

MIME media type name:  application
MIME subtype name:  rpki-manifest
Required parameters:  None
Optional parameters:  None
Encoding considerations:  binary
Security considerations:  Carries an RPKI Manifest [RFC6486]
Interoperability considerations:  None
Published specification:  This document
Applications that use this media type:  Any MIME-complaint transport
Additional information:
   Magic number(s):  None
   File extension(s):  .mft
   Macintosh File Type Code(s):
Person & email address to contact for further information:
   Geoff Huston <gih@apnic.net>
Intended usage:  COMMON
Author/Change controller:  Geoff Huston <gih@apnic.net>

7.1.2. application/rpki-roa

MIME media type name:  application
MIME subtype name:  rpki-roa
Required parameters:  None
Optional parameters:  None
Encoding considerations:  binary
Security considerations:  Carries an RPKI ROA [RFC6482]
Interoperability considerations:  None
Published specification:  This document
Applications that use this media type:  Any MIME-complaint transport
Additional information:
   Magic number(s):  None
   File extension(s):  .roa
   Macintosh File Type Code(s):
Person & email address to contact for further information:
   Geoff Huston <gih@apnic.net>
Intended usage:  COMMON
Author/Change controller:  Geoff Huston <gih@apnic.net>

7.2. RPKIリポジトリ名スキーム登録簿

IANAは、「RPKI Repository Name Scheme」(RPKIリポジトリ名スキーム)登録簿を作成した。この登録簿には、RPKIリポジトリ・オブジェクトの3文字のファイル名拡張子が含まれる。登録簿の内容はIETF Review [RFC5226]によって管理される。この登録簿の初期内容は以下のとおりである。

ファイル名拡張子	RPKIオブジェクト	出典
.cer	証明書	[RFC6481]
.crl	証明書失効リスト	[RFC6481]
.mft	マニフェスト	[RFC6481]
.roa	経路発信認可	[RFC6481]

⚠️ IANAのRPKIリポジトリ名スキーム(2023-12-15)

ファイル名拡張子	RPKIオブジェクト	出典
.asa	Autonomous System Provider Authorization (一時的 - expires 2024-11-08)	[draft-ietf-sidrops-aspa-profile-16]
.cer	証明書	[RFC6481]
.crl	証明書失効リスト	[RFC6481]
.gbr	ゴーストバスターズ・レコード	[RFC6493]
.mft	マニフェスト	[RFC6481]
.roa	経路発信認可	[RFC6481]
.sig	署名済みチェックリスト	[RFC9323]
.tak	トラストアンカー鍵 (TEMPORARY - expires 2024-07-27)	[draft-ietf-sidrops-signed-tal-11]

8. 謝辞

本文書は、スティーブン・ケント、マット・レペンスキ、マイケル・エルキンス、ラス・ハウスリー、ショーン・ターナーから有益なレビューコメントと意見の恩恵を受けている。

9. 参考文献

9.1. 引用規格

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

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.

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

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

[RSYNC] rsync web pages, <http://rsync.samba.org/>.

9.2. 参考規格

[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.

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

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", RFC 4387, February 2006.

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

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

[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.

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

[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.

[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.

著者のアドレス

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

ロバート・ルーマンズ
APNIC
メール: robertl@apnic.net
URI: http://www.apnic.net

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

変更履歴

2024.2.16
2024.3.24: IANA RPKIリポジトリ名スキーム
2024.4.12: AIA=機関情報アクセス

GitHubで編集を提案

要旨