要約

  • RFC 9891 は ACME アカウント側のチャレンジと、制限時間内に届く一つ以上の Bundle 応答を結び付ける。
  • 成功は、その時点でサーバーの方針が bundleEID の制御証拠を受け入れたことを示すだけで、識別子の割当権や証明書の導入を示さない。

応答が数分後に届く。送信元 Node ID は一致し、完全性ブロックも正しく、ダイジェストも期待値どおりだ。画面は「検証済み」になる。ここで運用者が問うべきなのは、何が証明されたかではなく、何までしか証明されていないかである。

RFC 9891 は Experimental RFC として bundleEID と bp-nodeid-00 を定義する。HTTPS 側の token-chal と Bundle 側の token-bundle を分離し、BP Agent が ACME アカウント鍵のフィンガープリントと合わせて応答を作る。一方の通信だけを見ても完全な応答は作れない。

クライアントが提示する RTT は目安にすぎず、権威ある測定値ではない。受理時間はサーバー方針が決める。応答には時間、送信元 Node ID、BIB、二つのトークン、アルゴリズム、Key Authorization の検査が必要だ。RFC 9172 は BPSec を、RFC 9174 は NODE-ID の比較と証明書プロファイルを与える。

RFC 9171 によれば、Node ID は BP ノードを識別する singleton EID だが、世界全体での一意性は保証されず、一つのノードが複数持つこともできる。したがって応答できた事実は、世界的な所有権を生まない。

複数視点の検証では、異なる送信元や経路から Bundle を送れる。しかし主視点と副視点の選択、許容する失敗数はサーバーの方針である。送信元が違っても、同じ回線や同じ完全性ゲートウェイに依存していれば障害領域は一つだ。RFC 9891 自身も、その有用性を実験対象としている。

完全性ゲートウェイはローカルな方法で送信元を確かめ、BIB を追加できる。受信側には、その Security Source がどの Node ID のために証言できるかを示す方針が要る。署名は保護されたデータの完全性を示すが、運営組織への委任までは示さない。

RFC 8555 の ACME 注文が証明書発行へ進んでも、RFC 9891 は鍵の配送、証明書の設定、失効情報、経路選択を対象外とする。発行成功と稼働成功を同じ状態にしてはならない。

IANA の ACME 登録簿と Bundle Protocol 登録簿はコード点を調整する。現場の状態は観測しない。Heng Lu の稼働コード優先、最小初期仕様、現実の層を重ねると、標準、方針、実行、結果を別々の証拠として保つべき理由が見える。

情報源