要約

  • RFC 9891 の rtt は、Challenge Bundle と Response Bundle の予想往復秒数をクライアントが伝える任意のヒントである。サーバーは実際の応答区間と上下限を決め、元の Challenge Bundle の Lifetime に対して到着を判定する。
  • 期限内の正しい応答が示すのは、一つの ACME アカウントが一つの挑戦時に Node ID を制御できたことだ。恒久的な所有、将来の経路、証明書の発行・導入、TCPCL セッション、アプリケーション結果までは示さない。

運用画面に rtt: 300 が現れた。担当者はそれを「五分の検証窓」と読み替えた。遠隔ノードが五分を予想したことと、CA が五分を受け入れたことは同じではない。

RFC 9891 は ACME に bundleEID 識別子と bp-nodeid-00 チャレンジを追加する。ACME サーバー側の BP Agent は、申告された DTN Node ID へ Challenge Bundle を送る。クライアントが準備した BP Agent は、挑戦とアカウント鍵に結び付く Response Bundle を返す。

常時接続を前提にしないネットワークでは、待つこと自体が正常な処理である。そこで必要なのは期限を消すことではなく、遅延情報と期限決定の権限を分けることだった。

ヒントはサーバーの時計を動かさない

クライアントは Response Object に予想 RTT を秒で入れられる。RFC 9891 はこれを authoritative ではない hint と明記する。サーバーは通常、その二倍を基礎に応答区間を計算し、ネットワーク固有の最小値と最大値を適用する。地上だけの DTN なら、最大値は六十秒を超えないことが推奨される。

深い遅延を持つ別のネットワークには別の上限があり得る。重要なのは数字の大小ではなく、決定主体である。クライアントは予定経路を知る。サーバーは保持できる検証状態、DoS 面、CA のリスク方針を知る。片方の観測が、もう片方の責任を奪わない。

クライアントは BP Agent の応答準備が整う前に Response Object を送ってはならない。Bundle が実際に通る経路は保証されないため、RTT は悲観的に見積もることが推奨される。ここでクライアントが所有するのは準備と情報品質であり、締切ではない。

Response Bundle 自身にも作成時刻と残り Lifetime がある。しかし受信側は、関連する Challenge Bundle の作成時刻と Lifetime で期限を検査する。戻り側が長い Lifetime を主張しても、元の窓を延長できない。

短い窓は攻撃面と資源保有を抑える一方、正当な断続ノードを排除する。長い窓は到達可能性を広げる一方、状態と検証経路を長く開く。これは利用者の一フィールドでは解消できない運用政策である。

証明は二つの経路を結合する

単に Bundle が戻るだけでは足りない。token-chal は ACME authorization ごとに生成され、ACME チャネルだけで伝わる。同じ authorization から複数の Challenge Bundle が出ても、この値は共通である。

一方、token-bundle は Bundle ごとに異なり、BP 経路上で見える。応答 Agent は両 token と ACME アカウント鍵の thumbprint を結び、Key Authorization の digest を生成する。この分割により、DTN を盗聴するだけの者も、ACME オブジェクトを見るだけの者も完全な応答を作れない。

サーバーは各 perspective について、期限内到着、検証対象と同一の Source Node ID、primary block と payload を覆う信頼済み BIB、token の一致、許容アルゴリズム、期待 digest を確認する。一項目でも欠ければ失敗する。期限内に応答がなければ、やはり失敗である。

ただし、失敗理由は同じではない。経路断、時計、BIB の信頼、アルゴリズム、Agent の準備、token 相関のどれでも invalid になり得る。subproblem を残さなければ、再試行や復旧判断を誤る。

成功の意味も限定される。特定アカウントと特定挑戦に対応する応答を、対象 Node ID から時間内に返せたという証拠である。名前の法的所有や、翌日の接続性を証明するものではない。

RFC 9171 では Node ID は BP Node を識別できる singleton Endpoint ID だが、世界的な一意性は保証されない。一つの node が複数の Node ID を持つこともできる。Administrative EID の一意性も、特定 URI scheme 内での話である。

IANA ACME レジストリと IANA Bundle Protocol レジストリは、bundleEID、bp-nodeid-00、管理レコード型、dtn と ipn を共通化する。レジストリは実装間の衝突を防ぐが、個々の Node ID や経路を観測しない。

多視点でも経路独立性は自動ではない

サーバーは複数の送信元や複数経路から Challenge Bundle を送れる。各 Bundle は独自 token を持つので、結果を混ぜずに評価できる。単一の経路上攻撃を避ける狙いだが、論理上複数でも同じゲートウェイや物理リンクを共有しているかもしれない。

RFC 9891 は全体判定をサーバー政策に委ねる。推奨例は、primary perspective が成功し、secondary の失敗が一つ以下なら成功とする。何を primary と呼ぶかも実装事項である。

したがって valid は生の観測値ではない。個別結果に政策を適用した結論である。個別行と政策版を失えば、「すべて成功」と「一部失敗を許容」が同じ緑色になってしまう。

Integrity Gateway はローカルな手段で Bundle source を確かめ、BIB を追加できる。受信側は、その Security Source がどの Node ID 範囲について証言できるかを設定する必要がある。暗号は証言の改変を防ぐが、証言者の権限範囲を定めない。

Heng Lu の最小初期仕様とローカルな将来判断が示す原則はここでも有効だ。標準は token、比較、整合性、期限という共通最小限を定める。許容遅延と組織間信頼は、結果を負担する参加者が決める。

valid authorization の先にある空白

RFC 8555 では challenge、authorization、order は別の状態を持つ。チャレンジが valid になっても、それはアカウントが識別子について期限付きで承認されたという意味であり、証明書そのものではない。

RFC 9891 の CSR は NODE-ID と DNS-ID、IP-ID を組み合わせ得る。すべての識別子が検証対象であり、CA はさらに発行方針、鍵用途、アルゴリズムを判断する。Node ID の成功だけで発行義務は生まれない。

RFC 9174 は、発行後の証明書を TCPCL で使う段階を扱う。証明書は NODE-ID と id-kp-bundleSecurity を含み得る。実際の handshake では DNS やネットワーク識別子、Node ID を policy に従って検証し、失敗すれば session を閉じる。

しかも RFC 9891 は、発行証明書を BP Agent へ設定する方法を implementation matter とする。authorization、issuance、installation、TLS selection、TCPCL session、Bundle forwarding、application result はそれぞれ証拠が必要である。

RFC 9172 の BPSec は block integrity を与える。BIB が成功しても、Security Source を制度的に信頼してよいかは別の設定である。

動くコードを第一の証拠とするなら、仕様の存在、サーバー設定、観測された挑戦、後続利用を分ける。現実の層と象徴的権力に照らせば、範囲を失った valid が恒久的な正しさに見える危険も理解できる。

クライアントは遅延を見積もった。その値は必要だった。サーバーは検証窓を握った。その責任も必要だった。戻ってきた証明は、限定されているからこそ信頼できる。

出典