要約

  • RFC 9891はIETFのExperimental仕様であり、BundleEIDの証明書アイデンティティとbundleEIDのACME識別子として表されるDTN Node IDをサーバーが検証できるようACMEを拡張する。
  • 証明材料は通常のACMEチャネルとBundle Protocolチャネルに分かれる。token-chalはACMEチャレンジの文脈に残り、token-bundleは個別のChallenge Bundleに対応し、Response Bundleのダイジェストは両方とそのBundleの受信に結び付く。
  • Node IDはsingletonのBundle Protocol Endpoint IDでなければならず、non-singleton EIDは似た文字列であっても有効なNode IDにはならない。
  • この仕組みはアカウント鍵の関与、特定Bundleの受信、正しいチャレンジへの応答を検査できるが、組織間の命名権、ゲートウェイ信頼、導入方式、ルーティング方針を決めるものではない。

ここでいうbundleEIDは、ACMEの識別子として使われるBundle Endpoint ID表現である。BundleEID証明書アイデンティティは、同種のアイデンティティを証明書の意味に置く。いずれも、任意の到達可能アドレスや、組織がすでに保有している名称権限と同一視してはならない。RFC 9891の検査の流れは明確だ。ACMEサーバーが認可とチャレンジを作成し、主張されたNode IDへ一つ以上のChallenge Bundleを送る。Node ID側のBP Agentが受信すると、クライアントはResponse Bundleを生成する。そのダイジェストは、ACMEアカウント・チャレンジのtoken-chal、そのBundleに固有のtoken-bundle、そして特定のChallenge Bundleを受信した事実に結び付かなければならない。アカウント鍵の関与とBP経路上の受信は同じ検証に置かれるが、材料が別チャネルから来る点は変わらない。

検証可能な最小フィクスチャは次のように記録できる。account=A17、token-chal=C-7f2、対象をsingletonのdtn://node.example/、送信されたChallenge Bundleのtoken-bundle=B-91a、返されたResponse Bundleのダイジェストをdigest(A17,C-7f2,B-91a,received-challenge)とする。検証者は、EIDがsingleton Node IDに解決されること、B-91aが実際に送信されたそのBundleに属すること、応答が正しいACMEアカウント文脈を使うこと、置換なしにダイジェストとチャレンジが対応することを個別に確認する。この表記は記録用の具体例であり、RFCが要求する文字列形式でも、実運用の存在を示すものでもない。

任意のintegrity gatewayはResponse Bundleの出所を証明できる。しかしRFCは、組織をまたぐ命名権、ゲートウェイ方針、信頼委任を定義していない。したがってゲートウェイの存在だけで、Node IDそのものが処理を完了したとはいえない。運用者は、ゲートウェイの主張、BP Agentの受信証拠、ACMEサーバーの元のチャレンジを別々に保持し、中継者の証言を端点の制御権と取り違えないようにする必要がある。RFC 9891はon-path攻撃を研究対象とし、多視点検証の価値を実験的な問題として扱う。DTNオーバーレイのトポロジーは基盤IP網と異なり得るため、観測点を増やせば自動的に保証が強くなるとは推論できない。

検証フィクスチャと運用者の判断経路

  1. 対象EIDを解析し、non-singleton EIDを拒否する。BundleEID識別子とBundleEID証明書アイデンティティを別の記録として残す。
  2. ACMEアカウント、token-chal、Challenge Bundle固有の文脈、token-bundle、送受信時刻、Response Bundleのダイジェストを保存する。
  3. 応答が対象Node IDのBP Agentから来たのか、任意のintegrity gatewayから来たのかを確認する。後者だけなら「ゲートウェイによる証言」と記録し、端点制御の結論に昇格させない。
  4. 必要なら複数視点で再観測するが、結果は実験的証拠としてラベル付けする。特定ネットワークの遅延、可用性、DoS耐性を宣言しない。
  5. いずれかの結び付きが失敗したら、発行または認可の継続を止め、ACMEの再試行、ルーティング調査、手動審査へ戻す。これは運用上の判断経路であり、RFCが定める導入手順ではない。

範囲外も明示しなければならない。RFC 9891は証明書の配備、秘密鍵のプロビジョニング、Bundleルーティング、レート制御、ACMEコンポーネントとBP Agentの通信方法を規定しない。資料から、本番導入の普及率や成功率、特定ネットワークの測定済み遅延・可用性・DoS耐性を導くことはできない。証明書インストールと秘密鍵ライフサイクルの統制も拡張の外にある。組織間のDTN命名権、ゲートウェイ信頼方針、多視点検証の有効性も未解決のままである。

出典