📚

RFC 9286: リソース公開鍵基盤(RPKI)のマニフェスト

2024/03/03に公開

Security

rfc

bgp

tech

要旨

本文書は、リソース公開鍵基盤(RPKI)で使用する「マニフェスト」を定義する。マニフェストとは、リポジトリの公開に責任を持つオーソリティに関連付けられたリポジトリ公開ポイント(ディレクトリ)内のすべての署名済みオブジェクト(ファイル)のリストを含む署名済みオブジェクト(ファイル)である。このリポジトリ公開ポイントで公開される各証明書、証明書失効リスト(CRL)、またはオーソリティによって発行された他のタイプの署名済みオブジェクトについて、マニフェストにはオブジェクトを含むファイル名とファイル内容のハッシュの両方が含まれる。マニフェストは、リライング・パーティー(RP)がリポジトリに対する特定の種類の攻撃を検出できるようにすることを目的としている。具体的には、RPはマニフェストの内容をリポジトリ公開ポイントから取得した署名済みオブジェクトと照合することで、リプレイ攻撃や、署名済みオブジェクトの稼働中の不正な変更や削除を検出することができる。この文書はRFC 6486を廃止する。

本文書の位置付け

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

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

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

著作権表示

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

1. はじめに

リソース公開鍵基盤(RPKI)[RFC6480]は、分散リポジトリ・システム[RFC6481]を利用して、リライング・パーティー(RP)が必要とするさまざまなオブジェクトを利用できるようにする。リポジトリ・システムに格納されているすべてのオブジェクトは、そのオブジェクトを作成した組織(エンティティ)によってデジタル署名されているため、これらの公開オブジェクトを変更する攻撃はRPによって検出できる。しかし、デジタル署名だけでは、署名されたオブジェクトの「古い」バージョン(つまり、有効期限は切れていないが、その後置き換えられたオブジェクト)を置き換える攻撃や、リポジトリに存在するはずのオブジェクトを削除する、稼働中の攻撃を防御できない。このような攻撃の検出を支援するため、RPKIリポジトリ・システムは「マニフェスト」と呼ばれる署名済みオブジェクトを利用する。

マニフェストとは、リポジトリ公開ポイント(ディレクトリ)において、公開に責任を持つオーソリティに関連するすべての署名済みオブジェクト(ファイル)を列挙した署名済みオブジェクトのことである。各マニフェストには、オーソリティのリポジトリ公開ポイントで公開されている署名済みオブジェクトについて、オブジェクトを含むファイル名とファイル内容のハッシュの両方が含まれる。マニフェストは、RPが公開ポイントでのオブジェクトの不正な削除や古いバージョンのオブジェクトの置き換えを検出できるようにすることを目的としている。マニフェストはまた、RPがリポジトリからオブジェクトを取得する際、オンパス攻撃から生じる類似の結果を検出できるようにすることも目的としている。マニフェストは、リポジトリの認証局(CA)公開ポイント(認証局が発行した下位証明書と証明書失効リスト(CRL)、および認証局が発行したエンド・エンティティ(EE)証明書によって検出される他の署名済みオブジェクトのファイルが格納されるディレクトリ)において使用されることを目的としている。

マニフェストはCRLに基づいてモデル化されている。これは、古いマニフェストの検出や、マニフェストのリプレイを利用した潜在的な攻撃の検出に関連する問題が、CRLの問題と類似しているためである。RPKIリポジトリには、CRLでカバーされないオブジェクト、例えば経路オリジン認証(ROA)[RFC6482]のようなデジタル署名されたオブジェクトが含まれるため、マニフェストのペイロード構文はCRLとは異なる。

本文書は[RFC6486]を廃止する。

1.1.要件言語

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

2. マニフェストの範囲

CAのリポジトリ公開ポイントに関連するマニフェストには、以下のリストが含まれる。

このCAが発行し、公開した(有効期限が切れていない、失効していない)証明書、
このCAが発行した最新のCRL、および
このCAが発行したEE証明書[RFC6487]を使用して検証可能な、すべての公開された署名済みオブジェクト(マニフェスト自身を除く)。

すべてのRPKI署名済みオブジェクトには、そのオブジェクトの暗号メッセージ構文(CMS)[RFC5652]のラッパーに、それを検証するために使用されるEE証明書[RFC6488]が含まれる。したがって、そのEE 証明をCAのリポジトリ公開ポイントで個別に公開する必要はない。

CAが鍵ロールオーバー操作[RFC6489]を実行する場合に発生する可能性があるような、複数のCAインスタンスが共通の公開ポイントを共有する場合、リポジトリ公開ポイントには複数のマニフェストが含まれる。この場合、各マニフェストには、関連するCAインスタンスの公開された最新のコレクションのみを記述する。

3. マニフェストの署名

CAのマニフェストは、EE証明書を使用して検証される。このEE証明書の SubjectInfoAccess (SIA)フィールドには、id-ad-signedObjectのaccessMethodオブジェクト識別子(OID)が含まれる。

CAは、生成された秘密鍵1つにつき、1つのマニフェストのみ署名しなければならず(MUST)、マニフェストの新しいバージョンごとに新しい鍵ペアを生成しなければならない(MUST)。この方法で使用される関連するEE証明書は、「1回限りの(one-time-use)」EE証明書と呼ばれる([RFC6487]のセクション3参照)。

4. マニフェストの定義

マニフェストは、[RFC6488]で規定されているように、RPKI署名済みオブジェクトである。RPKI署名済みオブジェクト・テンプレートは、マニフェスト構造のコンテキストにおいて以下のデータ要素を指定する必要がある。

⚠️ マニフェストファイルの中身

$ rpki-client -f ripe-ncc-ta.mft 
File:                     ripe-ncc-ta.mft
Hash identifier:          JCyqdB8P3aOAIcnw54UWbatEbc5i0SepPbP+k/pGLWI=
Subject key identifier:   FE:FB:5C:11:BF:A0:2F:47:DA:3F:05:16:DA:14:45:1D:35:D9:CC:9E
Authority key identifier: E8:55:2B:1F:D6:D1:A4:F7:E4:04:C6:D8:E5:68:0D:1E:BC:16:3F:C3
Certificate issuer:       /CN=ripe-ncc-ta
Certificate serial:       0108
Authority info access:    rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer
Subject info access:      rsync://rpki.ripe.net/repository/ripe-ncc-ta.mft
Manifest number:          4A
Signing time:             Mon 11 Dec 2023 12:36:21 +0000
Manifest this update:     Mon 11 Dec 2023 12:36:21 +0000
Manifest next update:     Mon 11 Mar 2024 12:36:21 +0000
Files and hashes:         1: 2a7dd1d787d793e4c8af56e197d4eed92af6ba13.cer (hash: 0F9XRQbaqcWSETf65J9Pml+0M2MHM49bPtAuDroOs4g=)
                          2: ec334d0f3a18be0021b7b8e842287641acb1731a.cer (hash: WJrr4EDq4Y4mkLYkHaLl75jYUgBW4oiSI/wjgD9N6vc=)
                          3: ripe-ncc-ta.crl (hash: sXQFogJ+w3/Uz0osrJ6ELOGLORYzkUhvHwe+c3Z9vCE=)
Validation:               OK
Signature path:           rsync://rpki.ripe.net/repository/ripe-ncc-ta.crl
                          rsync://rpki.ripe.net/repository/ripe-ncc-ta.mft
                          rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer
Signature path expires:   Mon 11 Mar 2024 12:36:21 +0000

⚠️ OpenSSLで中身を見る方法

証明書(CER)、CRLであれば、openssl x509で中身を見ることができるが、マニフェストの場合エラーになる。マニフェストのEE証明書は、CMSにバンドルされているため、CMSラッパーからEE証明書を取り出す必要があり(セクション2参照)、下記のコマンドを使う。

% openssl cms -verify -noverify -inform DER -in ripe-ncc-ta.mft -out /dev/null 2> /dev/null -certsout /dev/stdout | openssl x509 -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 264 (0x108)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = ripe-ncc-ta
        Validity
            Not Before: Dec 11 12:36:21 2023 GMT
            Not After : Mar 11 12:36:21 2024 GMT
        Subject: CN = fefb5c11bfa02f47da3f0516da14451d35d9cc9e
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:92:fa:a4:e3:cc:64:58:9b:78:27:b8:21:2c:27:
                    2a:c0:06:8f:0c:ad:c7:4e:b5:75:6e:b8:c8:38:82:
                    e1:5a:5f:62:cf:20:fd:9b:22:f8:18:a0:3a:41:6a:
                    65:c8:03:1c:5b:39:19:2a:33:cc:7d:6b:1f:6f:bd:
                    28:0c:bb:85:97:64:b1:57:ed:5f:57:a0:4d:68:f7:
                    12:c9:dc:ef:1a:cc:2c:e4:15:6d:1c:9c:56:9b:86:
                    53:0b:47:13:51:d6:af:b9:5e:53:a6:dc:5c:a8:be:
                    20:34:51:f4:2f:ec:61:42:6b:36:d1:ba:61:27:df:
                    69:1e:cb:c8:8c:1f:90:2a:e8:5f:c4:f0:4a:4e:fa:
                    46:9e:e9:e4:29:8a:17:2f:5c:cb:c7:db:e9:38:55:
                    90:14:98:bb:1b:7e:cb:9a:64:40:7d:b7:d6:cb:c1:
                    e9:53:48:dc:94:58:5d:82:8c:78:7c:3a:5d:01:48:
                    05:c2:a5:98:26:93:c3:50:6a:86:4c:ea:e4:4a:24:
                    ca:81:c3:cd:c7:68:5a:a3:ab:8a:6f:67:3a:a8:b8:
                    e0:ee:b4:c8:81:d1:b4:27:07:99:4f:c2:96:d0:4c:
                    e0:d8:59:0b:c5:f0:9f:84:b3:ec:79:26:da:a0:4d:
                    de:60:6d:48:81:ee:48:71:bc:ac:48:2c:35:20:67:
                    ca:bb
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                FE:FB:5C:11:BF:A0:2F:47:DA:3F:05:16:DA:14:45:1D:35:D9:CC:9E
            X509v3 Authority Key Identifier: 
                E8:55:2B:1F:D6:D1:A4:F7:E4:04:C6:D8:E5:68:0D:1E:BC:16:3F:C3
            X509v3 Key Usage: critical
                Digital Signature
            Authority Information Access: 
                CA Issuers - URI:rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer
            Subject Information Access: 
                Signed Object - URI:rsync://rpki.ripe.net/repository/ripe-ncc-ta.mft
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:rsync://rpki.ripe.net/repository/ripe-ncc-ta.crl
            X509v3 Certificate Policies: critical
                Policy: ipAddr-asNumber
            sbgp-ipAddrBlock: critical
                IPv4: inherit
                IPv6: inherit

            sbgp-autonomousSysNum: critical
                Autonomous System Numbers:
                  inherit

    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        9f:02:61:45:ef:de:1a:e4:c6:2d:68:a9:df:61:04:aa:e4:fe:
        d9:74:a5:44:0e:f3:a1:d1:5a:c8:99:32:85:b9:43:92:8f:34:
        ad:13:67:a3:09:78:44:f5:30:93:02:83:d1:dd:b1:c5:f5:3a:
        9e:08:76:c8:ea:15:54:57:4f:f3:8d:49:a6:ca:4a:9e:9a:ca:
        8d:a1:81:ab:22:a6:b1:b1:81:8e:70:88:29:86:43:0c:7d:d9:
        5c:ed:cf:15:31:4a:d4:12:7b:b0:f9:b0:83:4c:1c:f9:90:61:
        a5:e9:69:f2:83:d2:db:eb:6c:12:16:11:30:8c:5b:ee:cb:ee:
        73:11:41:b1:be:97:b4:e8:42:21:d6:4b:b9:9d:6e:48:7c:ed:
        1a:83:24:87:05:ac:78:ba:c4:94:34:a3:d7:b0:27:c1:68:59:
        56:bc:4d:48:6e:80:51:22:5d:7e:df:dd:ac:a7:5c:e8:e2:03:
        f0:a1:c3:3c:f8:ab:f6:84:d4:0a:df:1c:bb:43:66:e2:66:d4:
        fd:ed:d7:3c:c4:9a:ff:53:d4:b9:c6:f0:3b:de:15:12:5d:cd:
        ec:1d:27:28:4d:79:59:5d:6b:91:12:6e:a5:97:2e:f4:e7:89:
        be:60:0e:cc:18:58:49:33:f6:f4:48:6f:81:0d:7a:f3:68:50:
        38:39:63:55
%

4.1. eContentType

マニフェストのeContentTypeはid-ct-rpkiManifestとして定義され、1.2.840.113549.1.9.16.1.26の数値OIDを持つ。

   id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                             rsadsi(113549) pkcs(1) pkcs9(9) 16 }
   id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
   id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }

4.2. eContent

マニフェストの内容は、Distinguished Encoding Rules (DER)[X.690]を使用して ASN.1で符号化される。マニフェストの内容は以下のように定義される。

   Manifest ::= SEQUENCE {
     version     [0] INTEGER DEFAULT 0,
     manifestNumber  INTEGER (0..MAX),
     thisUpdate      GeneralizedTime,
     nextUpdate      GeneralizedTime,
     fileHashAlg     OBJECT IDENTIFIER,
     fileList        SEQUENCE SIZE (0..MAX) OF FileAndHash
     }
   FileAndHash ::=   SEQUENCE {
     file            IA5String,
     hash            BIT STRING
   }

4.2.1.Manifest

manifestNumber、thisUpdate、およびnextUpdateフィールドは、X.509 CRLの対応するフィールドをモデルにしている([RFC5280]参照)。CRLと同様に、マニフェストは名目上、nextUpdateで指定された時刻まで、またはより大きなマニフェスト番号(manifestNumber)を持つマニフェストが発行されるまでのいずれか早い時刻の方が最新である。

マニフェストの検証には「1回限りの」EE証明書が使用されるため、EE証明書は、CAのCRLの不必要な増大を防ぐために、マニフェストのthisUpdateからnextUpdateまでのインターバルと一致する有効期間で発行されなければならない(MUST) 。

マニフェスト構造のデータ要素は以下のように定義される。

version:
このバージョンのマニフェスト仕様のバージョン番号は0でなければならない(MUST)。

manifestNumber:
このフィールドは整数で、特定の公開ポイントに対して新しいマニフェストが発行されるたびに(1ずつ)インクリメントされる。このフィールドにより、RPは公開されたマニフェストの順序のギャップを検出することができる。

マニフェストはCRLの仕様に基づいてモデル化されているため、manifestNumberはCRLNumberに似ており、manifestNumberに使用できる数値の範囲に関しては[RFC5280]のCRLNumber値に関するガイダンスが適切である。マニフェスト番号は長い整数が含まれることが予想される。マニフェスト検証者は、最大20オクテットの数値を処理できなければならない(MUST)。適合するマニフェスト発行者は、20オクテットを超える数値を使用してはならない(MUST NOT)。発行者は、新しく生成されるマニフェストごとに、このフィールドの値を単調に増加させなければならない(MUST) 。各RPは、「新しい」マニフェストが、以前に検証されたマニフェストよりも大きなmanifestNumberを含んでいることを検証しなければならない(MUST)。「新しい」マニフェストが、以前に検証されたマニフェストのmanifestNumber値と等しいか、それよりも小さなmanifestNumber値を含む場合、RPはセクション6.6に記載されているように、ローカルにキャッシュされたバージョンのオブジェクトを使用する必要がある(SHOULD)。

thisUpdate:
このフィールドは、マニフェストが作成された時刻が含む。このフィールドは、[RFC5280]で同名のCRLフィールドに対して規定されているのと同じ形式制約を持つ。発行者は、このフィールドの値が以前に生成されたマニフェストよりも新しいことを保証しなければならない(MUST)。各RPは、このフィールド値が、自身が検証した最新のマニフェストよりも大きい(新しい)ことを検証しなければならない(MUST)。「新しい」マニフェストとされるマニフェストのこのフィールドが、以前に検証されたマニフェストよりも小さい(新しくない)場合、RPはセクション6.6に記載されているように、ローカルにキャッシュされたバージョンのオブジェクトを使用する必要がある(SHOULD)。

Errata

これは報告済みで、検証済みではないことに留意。

下記に書き換える。

thisUpdate:

このフィールドには、マニフェストが作成された時刻が含む。このフィールドは、[RFC5280]で同名のCRLフィールドに対して規定されているのと同じ形式制約を持つ。発行者は、このフィールドの値が現在時刻と等しく、かつ以前に生成されたマニフェストのthisUpdate以上であることを確認しなければならない(MUST)。各RPは、このフィールド値が、そのRPが検証した最新のマニフェストよりも大きいか等しいか(同じか新しいか)を検証しなければならない(MUST)。「新しい」マニフェストと称されるこのフィールドが、以前に検証されたマニフェストよりも小さい(新しくない)と仮定する。その場合、RPはセクション6.6で記載されているように、キャッシュされたバージョンのオブジェクトを使用する必要がある(SHOULD)。

注記:

まず第一に: 以前の文章では、thisUpdateが現在時刻を含まれなければならない(MUST)ということが明示されていなかった。

第二に、実際には(同期APIへの複数の呼び出しなど)複数のマニフェストが同じthisUpdateで発行される可能性がある。以前の文章では、これは技術的には誤発行となる。提案された文章では、複数のマニフェストを同じ秒数で発行することができる。

nextUpdate:
このフィールドは、次に予定されたマニフェストが発行される時刻を含む。nextUpdateの値はthisUpdateの値より後でなければならない(MUST)。GeneralizedTime値の仕様は、thisUpdateフィールドに要求される仕様と同じである。

オーソリティがリポジトリ公開ポイントで公開しているアイテムのいずれかを変更した場合、オーソリティは新しいマニフェストを発行しなければならない(MUST)。公開時点でオブジェクトに変更がない場合でも、nextUpdate時刻より前に新しいマニフェストを発行しなければならない(MUST)。各マニフェストはCRLを含んでおり、新しいCRLが公開されるとマニフェストが再発行されるため、マニフェストのnextUpdateフィールドはCRLのnextUpdateフィールドのフィールドと一致する必要がある(SHOULD)。新しいマニフェストが現在のマニフェストのnextUpdateで指定された時刻より前に発行された場合、CAは古いマニフェストに対応するEE証明書を失効させる新しいCRLも発行しなければならない(MUST)。

fileHashAlg:
このフィールドは、オーソリティがリポジトリに置いたファイルをハッシュ化するために使用されるハッシュ・アルゴリズムのOIDを含む。使用するハッシュ・アルゴリズムは、「RPKIのアルゴリズムと鍵サイズのプロファイル」仕様[RFC7935]に準拠しなければならない(MUST)。

fileList:
このフィールドは、FileAndHashオブジェクトのシーケンスである。オーソリティによって、(この公開時点で)公開された、現在有効な署名済みオブジェクトごとに1つのFileAndHashエントリがある。各FileAndHashは、リポジトリ公開ポイント(ディレクトリ)にある、問題のオブジェクトを含むファイル名と、そのファイルの内容のハッシュで構成される順序ペアである。

4.2.2. FileAndHashオブジェクトの名前

fileListに表示される名前は、a-z、A-Z、0-9、-(ハイフン)、または_ (下線)から選ばれた1つ以上の文字と、.(ドット)1文字、それに続く3文字の拡張子で構成されなければならない(MUST)。拡張子は、 IANA[IANA-NAMING]が管理する「RPKIリポジトリ名スキーム」レジストリに列挙されている拡張子のいずれかでなければならない(MUST)。

例として、「vixxBTS_TVXQ-2pmGOT7.cer」は有効なファイル名である。

上の例では、ファイル名に大文字と小文字が混在している。CAとRPは、大文字と小文字を区別(case-sensitive)し、大文字と小文字を区別して保存する方法(case-preserving)でファイルシステム操作を実行できなければならない(MUST)。

4.3. Content-Type属性

必須のcontent-type属性は、そのattrValuesフィールドをeContentTypeと同じOIDを設定しなければならない(MUST)。このOIDはid-ct-rpkiManifestで、1.2.840.113549.1.9.16.1.26の数値を持つ。

4.4.マニフェストの検証

マニフェストが有効かどうかを判断するには、RPは[RFC6488]で規定されているチェックに加えて、以下のチェックを実行しなければならない(MUST)。

EncapsulatedContentInfoのeContentTypeはid-ad-rpkiManifest(OID 1.2.840.113549.1.9.16.1.26)であること。
rpkiManifestのバージョンは0であること。
rpkiManifestでは、thisUpdateはnextUpdateよりも前であること。

注: マニフェストのeContentのthisUpdateとnextUpdateフィールドは、マニフェストに関連付けられたCRLの対応するフィールドと一致しなければならない(MUST)が、RPは、これらのフィールドが同一ではないという理由だけでマニフェストを拒否してはならない(MUST NOT)。

上記の手順によってマニフェストが無効であることが示された場合、そのマニフェストは破棄され、マニフェストが存在しないものとして扱われなければならない(MUST)。

5.マニフェストの生成

5.1.マニフェストの生成手順

RPKIリポジトリ・システム内のCA公開ポイントについて、CAは以下の手順を実行して、マニフェストを生成しなければならない(MUST)。

「1 回限り使用の」EE証明書で使用する新しい鍵ペアを生成する。
この鍵ペアのEE証明書を発行する。CAは、置き換えられるマニフェストに使用されるEE証明書を失効しなければならない。

このEE証明書は、 accessMethod OID値がid-ad-signedObjectであるSIA拡張アクセス記述フィールドを持たなければならない(MUST)。ここで関連付けられたaccessLocationは、マニフェストの公開ポイントをオブジェクトURLとして参照する。(RPはこれらの両方の構文制約を検証することが求められる。)

このEE証明書は、リソースセットの明示的な記述ではなく、「inherit」属性を使用してインターネット番号リソース(INR)を記述しなければならない(MUST)([RFC3779]を参照)。(RPはこれを確認する必要がある。)

EE証明書の有効期間は、マニフェストのeContent 指定されているthisUpdateおよびnextUpdateの時間と正確に一致しなければならない(MUST)。(RPは、有効期間の不整合自体をエラーとみなしてはならない(MUST NOT)。)
EE証明書は、オーソリティのリポジトリ公開ポイントで公開してはならない(MUST NOT)。
マニフェストのコンテンツを構築する。

マニフェストの内容は、セクション4.2.1に記載されている。マニフェストの fileListには、このリポジトリ公開ポイント(ディレクトリ)で公開された、このCAが発行した各オブジェクトのファイル名とハッシュのペアが含まれる。マニフェストに含まれるオブジェクトのコレクションには、CAのリポジトリ公開ポイントで公開されている、このCAが発行したすべての証明書、CAが発行した最新のCRL、およびリポジトリ公開ポイントで公開されたこのCAが発行したEE証明書によって検証されたすべてのオブジェクトが含まれる。(セクション6.1から6.5では、ここで記載されているマニフェストの内容をサポートするためにRP が実行しなければならない検査について記述している。)

マニフェストが署名される前にマニフェスト自体のハッシュを計算することは不可能であるため、マニフェストは自己参照 (つまり、それ自身のファイル名とハッシュ)が含まれないことに留意すること。
CMS SignedDataのcontent-type(セクション4で指定)を使用してマニフェスト・コンテンツをカプセル化し、EE証明書に含まれるサブジェクト鍵に対応する秘密鍵を使用してマニフェストに署名し、マニフェストによって記述されるリポジトリ・システム公開ポイントでマニフェストを公開する。(RPはCMS署名を検証する必要がある。)
鍵ペアは1度しか使用されないため、この鍵ペアに関連付けられた秘密鍵を破棄しなければならない(MUST)。

5.2.マニフェスト生成に関する考慮事項

新しいマニフェストは、nextUpdate時刻までに発行し、公開しなければならない(MUST)。

オーソリティは、公開ポイント内のオブジェクトに加えられた変更の確定と併せて、新しいマニフェストを発行しなければならない(MUST)。公開ポイント内の名前付きオブジェクトが置き換えられた場合、オーソリティは、置き換えられた各オブジェクトのファイルハッシュが新しいマニフェスト内で適宜更新されるようにしなければならない(MUST)。さらに、オーソリティは、置き換えられた各オブジェクトに関連付けられた証明書(CRLを除く)が失効していない場合、その証明書を失効しなければならない(MUST)。オーソリティは、リポジトリの変更の範囲内で公開リポジトリに対して多数のオブジェクト操作を実行から、この変更の範囲内のすべての操作をカバーする1つのマニフェストを発行してもよい(MAY)。リポジトリ・オペレータは、リポジトリ公開ポイント(ディレクトリ)および関連するマニフェストの更新中に、リポジトリ上で取得操作を実行しているRPが一貫性のない一時的な中間状態にさらされるリスクを、可能な限り軽減する何らかの形式のリポジトリ更新手順を実装しなければならない(MUST)。

マニフェスト・オブジェクトURLは発行された証明書のSIAに含まれるため、新しいマニフェストは以前に発行された証明書のマニフェスト・オブジェクトURLを無効にしてはならない(MUST NOT)。このことは、リポジトリ内のマニフェストの公開名は、オブジェクトURLの形式で、マニフェスト生成サイクル全体にわたって変更されないことを意味する。

CAエンティティが鍵ロールオーバーを実行する場合、エンティティは2つのCAインスタンスを同じリポジトリ公開ポイントに同時に公開することを選択してもよい(MAY)。この場合、共通のリポジトリ公開ポイント(ディレクトリ)に公開されるアクティブなCAインスタンスごとに関連する1つのマニフェストが存在する。

6. リライング・パーティーによるマニフェストの処理

各RPは、CAの現マニフェストを使用して、基本的なRPKIオブジェクト(証明書、ROA、CRL)の検証に使用する署名済みオブジェクト・セットにリストされたファイルの追加を管理しなければならない(MUST)。マニフェストにリストされていないファイルは、これらのオブジェクトの検証に使用してはならない。ただし、マニフェストにリストされていないファイルは、ブロジェクトタイプのプロファイルでそのような動作が許可される(または要求される)と明示されている場合、他の署名済みオブジェクトの検証に使用してもよい(MAY)。マニフェストにリストされていないファイルに依存すると、攻撃者がそのようなオブジェクトに対して置換攻撃を許してしまう可能性があることに留意する。

前述したように、マニフェストは、RPがリポジトリデータの操作、CAまたはリポジトリ・マネージャによるエラー、および/またはRPとリポジトリ間の通信チャネルに対するアクティブな攻撃を検出できるように設計されている。フェッチ操作中に、マニフェストにリストされているすべてのファイルをRPが取得できない限り、フェッチは失敗したとみなされ、RPは後でフェッチを再試行しなければならない(MUST) 。

[RFC6480]は、RPKIモデルがインクリメンタルなフェッチを採用することを提案している(ただし、強制はしていない)。例えば、RPは、ローカルキャッシュに表示された前回のフェッチが成功したときから新規または変更された場合にのみ、公開ポイントからファイルを転送する。この文書では、この操作を実行するためにRPと公開ポイントが採用する基本的なファイル転送メカニズムの詳細にかかわる文言は避ける。したがって、「フェッチ」という用語は、CA証明書のSIAから抽出されたid-ad-rpkiManifest URIと一致する公開ポイントで、ファイル一式を取得しようと試みる操作を指す(下記参照)。

フェッチが失敗した場合、フェッチ中に発生した問題は後続のフェッチが解決すると想定する。正常なフェッチが実行されるまで、RPは以前の成功したフェッチからキャッシュされたデータを使用する必要がある(SHOULD)。この応答は、RPが公開ポイントに関連付けられたデータを誤って解釈し、無効な経路を有効として扱ったり、その逆を行ったりすることを防ぐことを目的としている。

以下で説明する処理は、同じローカル・キャッシュとRPKIリポジトリ・データにアクセスできるすべてのRPが、同じ検証済みリポジトリ・ファイル・セットを取得できるように設計されている。RPKIデータの検証に関して、各RPが取得したファイルを処理する際に発生する可能性のある競合を、各RPがどのように解決するかに依存するため、RPが同じ結果を達成することを保証するものではない。さらに、運用中、異なるRPが異なるタイミングでリポジトリにアクセスし、一部のRPでローカルキャッシュの障害が発生する可能性があるため、RPKIデータの取得または検証に関して、すべてのRPが同じ結果を達成する保証はない。

特定のCAインスタンスのマニフェストとCRLの間には、「鶏と卵」の関係があることにも留意する。現マニフェストのEE証明書が失効している場合、つまり、現CRLに記載されている場合、CAまたは公開ポイント・マネージャは重大なエラーを犯したことになる。この場合、フェッチは失敗する。セクション6.6に進む。同様に、フェッチ中に取得された有効な現マニフェストにCRLが記載されていない場合、フェッチは失敗している。CRLが欠落しているとみなされるため、セクション6.6に進む。

6.1.マニフェスト処理の概要

所定の公開ポイントについて、RPは公開ポイントにどの署名済みオブジェクト・ファイルが受け入れられるかを判断するため、一連のテストを実行しなければならない(MUST)。以下で説明するテスト(セクション6.2～6.5)は、CA証明書のSIAから抽出したid-adrpkiManifest URIによって識別されるマニフェストを使用して実行される。マニフェストによって参照されるすべてのファイルは、(同じ)CA証明書のSIAからid-ad-caRepository URIによって指定された公開ポイントに配置しなければならない(MUST)。マニフェストとそれが参照するファイルは、同じ公開ポイントに存在しなければならない(MUST)。RPが、マニフェスト上に表示されるが、マニフェストと同じ公開ポイントに存在しないファイルに遭遇した場合、RPはフェッチの失敗として処理しなければならず(MUST)、警告を発行しなければならない(MUST)(下記のセクション6.6参照)。

CAの鍵ロールオーバー[RFC6489]の間、複数の異なるCAインスタンスの署名済みオブジェクトが同じ公開ポイントに表示されることに留意する。マニフェスト処理は、各CA証明書のSIA id-ad-rpkiManifest URIを指針として、CAインスタンスごとに個別に実行される。

6.2. CAのマニフェストの取得

RPは、CA証明書内のSIA id-adrpkiManifest URIによって識別されるマニフェストをフェッチしなければならない(MUST)。 RPがこのURIを使用してマニフェストを取得できない場合、またはマニフェストが有効ではない場合(セクション4.4)、RPはこれをフェッチ失敗として扱わなければならない(MUST) 。そして、セクション6.6に進む。それ以外の場合は、セクション6.3に進む。

6.3. 古いマニフェストおよび/または早期に発行されたマニフェストの検出

RPは、(UTCに変換された)現在時刻がthisUpdateとnextUpdateの間にあることを確認しなければならない(MUST) 。現在時刻がこのインターバル内にある場合、セクション6.4に進む。現在時刻がthisUpdateより前の場合は、CAがエラーを起こしたか、RPのローカルな時刻の考え方が間違っている可能性がある。RPはこれをフェッチ失敗として扱わなければならない(MUST) 。そして、セクション6.6に進む。現在時刻がnextUpdateより後の場合、マニフェストは古くなっている。RPはこれをフェッチ失敗として扱わなければならない(MUST)。そして、セクション6.6に進む。それ以外の場合は、セクション6.4に進む。

6.4.マニフェストで参照されるファイルの取得

RPは、マニフェスト(fileList)にリストされたすべてのファイルを公開ポイントから取得しなければならない(MUST) 。マニフェストにリストされたファイルの中に、公開ポイントから取得できないものがある場合、RPはこれをフェッチ失敗として扱わなければならない(MUST)。そして、セクション6.6に進む。それ以外の場合は、セクション6.5に進む。

6.5.ファイル名とハッシュの一致

RPは、マニフェストにリストされた各ファイルのハッシュ値が、公開ポイントから取得したファイルをハッシュ化して得られた値と一致することを検証しなければならない(MUST)。マニフェストにリストされたファイルの計算されたハッシュ値が、マニフェストに含まれるハッシュ値と一致しない場合、フェッチ失敗となり、RPはそれに応じて応答しなければならない(MUST)。そして、セクション6.6に進む。

6.6. フェッチ失敗

セクション6.2から6.5で挙げたいずれかの理由でフェッチが失敗した場合、RPはこのCAインスタンスに関する処理終了の理由を示す警告を発行しなければならない(MUST)。この警告を人間のオペレータに通知することが推奨される(RECOMMENDED)。

処理の終了とは、RPがこのCAインスタンスに関連付けられたオブジェクトのキャッシュ・バージョンを、それらが失効するか、フェッチが成功したオブジェクトに置き換えられるまで使用し続ける必要がある(SHOULD)ことを意味する。これは、RPがこのCAインスタンスのデータをフェッチし処理するようにスケジュールされている次のインターバルまで、RPが下位の署名オブジェクト(下位のCA証明書など)をフェッチして検証を試みてはならない(MUST NOT)ことを意味する。

7. 公開リポジトリ

RPKIの公開システム・モデルでは、すべての公開ポイントが1つ以上のCAに関連付けられ、空ではないことが必要である。CAに関連する公開ポイントが作成されると、CAはCRLだけでなくマニフェストも作成して公開しなければならない(MUST)。CAのマニフェストには、このマニフェストの範囲に対応する少なくとも1つのエントリ、つまり、CAによって発行されたCRL[RFC6481]が必ず含まれる。

RPKI[RFC6488]で公開された署名済みオブジェクトはすべて、EE 証明書を発行したCAのリポジトリ公開ポイントで公開され、そのCA証明書に関連するマニフェストにリストされる。

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

マニフェストは、RPKI RPに追加の保護レベルを提供する。マニフェストは、RPがリポジトリ・オブジェクトが削除されているか、隠蔽されているか、その他の方法で一覧から削除されているか、またはオブジェクトの新しいバージョンの公開が抑制されている(オブジェクトの古いバージョンが置き換えられている)かどうかをRPが判断するのに役立つ。

マニフェストは、そのような形式のリポジトリ取得操作の破損の影響を修復することはできない。しかし、マニフェストを使用すると、リポジトリの取得操作が安全でないチャネルを介して行われた場合でも、RPがリポジトリのローカルに保持されたコピーが完全かつ最新のコピーであるかどうかを判断することができる。マニフェストと取得されたリポジトリの内容が異なる場合、マニフェストは、どのリポジトリ・オブジェクトが不足しているか、無関係か、または置き換えられたかに関して、差分セットを形成するかを判断するのに役立つ。

マニフェストの署名構造とnextUpdate値の使用により、RPはマニフェスト自体が改変の対象であるかどうかを判断できる。すべてのリポジトリ公開ポイントが少なくとも1つのマニフェストを含むという要件により、RPはマニフェスト自体が表示されなくなったかどうかを判断することができる。マニフェストに対するこのような攻撃は、マニフェスト更新の定期スケジュールの時間枠内で検出可能である。より細かい時間枠内でのリプレイ攻撃は、マニフェスト構造で必ずしも検出できるとは限らない。

9. IANA に関する考慮事項

「RPKI Signed Objects」レジストリは、もともと[RFC6488]で作成され、登録されていた。「RPKI Repository Name Schemes」レジストリは[RFC6481]によって作成され、最初の3文字のファイル名拡張子のうち4つを作成した。IANAは、「RPKI Signed Objects」レジストリの「Manifest」行の参照を更新し、本文書を指すようにした。

また、IANAは以下のエントリを更新し、RFC 6486の代わりに本文書を参照するようにした。

「SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)」レジストリのid-mod-rpkiManifest (60)
「SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)」レジストリのid-ct-rpkiManifest (26)
rpki-manifestのアプリケーション・メディア・タイプ登録の「Security considerations」エントリ

他のアクションは必要ない。

10.参考文献

10.1. 引用規格

[IANA-NAMING] IANA, "RPKI Repository Name Schemes", https://www.iana.org/assignments/rpki/.

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

[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, DOI 10.17487/RFC5280, May 2008, https://www.rfc-editor.org/info/rfc5280.

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

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, https://www.rfc-editor.org/info/rfc6482.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012,https://www.rfc-editor.org/info/rfc6487.

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

[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, https://www.rfc-editor.org/info/rfc7935.

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

[X.690] International Telecommunication Union, "Information technology - ASN.1 encoding rules: Specification of BasicEncoding Rules (BER), Canonical Encoding Rules (CER) andDistinguished Encoding Rules (DER)", ITU-T Recommendation X.690, February 2021, https://www.itu.int/rec/T-REC-X.690-202102-I/en.

10.2. 参考規格

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, https://www.rfc-editor.org/info/rfc3779.

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

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

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, https://www.rfc-editor.org/info/rfc6486.

[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, February 2012, https://www.rfc-editor.org/info/rfc6489.

付録A. ASN.1 モジュール

    RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
                   pkcs(1) pkcs9(9) smime(16) mod(0) 60 }

DEFINITIONS EXPLICIT TAGS ::=
   BEGIN
   -- EXPORTS ALL --
   IMPORTS
     CONTENT-TYPE
     FROM CryptographicMessageSyntax-2010 -- in RFC 6268
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
   -- Manifest Content Type
   ct-rpkiManifest CONTENT-TYPE ::=
       { TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest }
   id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
   id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
   id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
   Manifest ::= SEQUENCE {
      version        [0] INTEGER DEFAULT 0,
      manifestNumber     INTEGER (0..MAX),
      thisUpdate         GeneralizedTime,
      nextUpdate         GeneralizedTime,
      fileHashAlg        OBJECT IDENTIFIER,
      fileList           SEQUENCE SIZE (0..MAX) OF FileAndHash
      }
   FileAndHash ::= SEQUENCE {
      file  IA5String,
      hash  BIT STRING
      }
   END

Errata

fileList           SEQUENCE SIZE (0..MAX) OF FileAndHash

ではなく、

fileList           SEQUENCE SIZE (1..MAX) OF FileAndHash

注記:

セクション7 では、「CAのマニフェストは常に少なくとも1つのエントリが含まれる」と規定されているため、サイズ0のfileListシーケンスは無効である。

付録 B. RFC 6486以降の変更点

2019年、おそらくオリジナル[RFC6486]仕様の曖昧さが認識されたことが原因で、複数のRP実装が脆弱な立場にあることが明らかになった。本文書は、グローバルなインターネット・ルーティング・システムにおける実際の導入経験に照らして、RPKIマニフェストの革新的な概念と適用を明確にし、将来の問題となるケースを回避しようとするものである。

以下のリストは、RFC 6486と本文書の間の変更点をまとめたものである:

「逐次使用(sequential-use)」のEE証明書を禁止し、代わりに「1回限り使用(one-time-use)」のEE証明書を義務付ける。
マニフェストEE証明書は、CRLのthisUpdateおよびnextUpdateと一致するマニフェストeContentで指定されたインターバルと一致する有効期間で発行されることを明確化する。
manifestNumberは1ずつ単調にインクリメントされることを明確化する。
CA発行者は、該当するCRLのnextUpdateをマニフェストのnextUpdateに含めることを推奨する。
FileAndHashファイル名に有効な文字セットを制限する。
マニフェストにリストされているファイル一式を取得できないRPは、失敗状態にあると見なされ、その場合、(利用可能であれば)以前の試行によるキャッシュ・データを使用する必要があることを明確化する。
現在のCRLが存在し、リストされ、検証されているという要件を明確化する。
「ローカル・ポリシー」という概念を削除する。

謝辞

著者らは、マニフェスト仕様の作成におけるジョージ・マイケルソンとランディ・ブッシュの貢献に感謝したい。さらに、マニフェストの検証とRPの動作の明確にする上で、マーク・レイノルズおよびクリストファー・スモールの支援に感謝する。また、著者らは、本文書の有用なレビューを提供してくれたティム・ブリュインツェルス、ジョブ・スナイダーズ、オレグ・ムラフスキー、ショーン・ターナー、アディアント・ウィビソノ、マレー・クチェラウィ、フランチェスカ・パロンビーニ、ロマン・ダニリュー、ラース・エガート、ロバート・ウィルトン、およびベンジャミン・カドゥクに感謝する。

著者のアドレス

ロブ・オースタイン
Arrcus, Inc.
メール: sra@hactrn.net

ジェフ・ヒューストン
APNIC
6 Cordelia St
South Brisbane QLD 4101
オーストラリア
メール: gih@apnic.net

スティーブン・ケント
Independent
メール: kent@alum.mit.edu

マット・レピンスキー
New College Florida
5800 Bay Shore Rd.
Sarasota, FL 34243
アメリカ合衆国
メール: mlepinski@ncf.edu

変更履歴

2024.2.21
2024.2.23: Errataを追記
2024.3.3
2024.3.5: マニフェスト番号について (セクション4.2.1)

GitHubで編集を提案

要旨

本文書の位置付け

著作権表示

1. はじめに

1.1.要件言語

2. マニフェストの範囲

3. マニフェストの署名

4. マニフェストの定義

4.1. eContentType

4.2. eContent

4.2.1.Manifest

4.2.2. FileAndHashオブジェクトの名前

4.3. Content-Type属性

4.4.マニフェストの検証

5.マニフェストの生成

5.1.マニフェストの生成手順

5.2.マニフェスト生成に関する考慮事項

6. リライング・パーティーによるマニフェストの処理

6.1.マニフェスト処理の概要

6.2. CAのマニフェストの取得

6.3. 古いマニフェストおよび/または早期に発行されたマニフェストの検出

6.4.マニフェストで参照されるファイルの取得

6.5.ファイル名とハッシュの一致

6.6. フェッチ失敗

7. 公開リポジトリ

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

9. IANA に関する考慮事項

10.参考文献

10.1. 引用規格

10.2. 参考規格

付録A. ASN.1 モジュール

付録 B. RFC 6486以降の変更点

謝辞

著者のアドレス

変更履歴

Discussion