要約

  • 0-RTT を使えないことは、CMC の HTTP POST が再送に敏感だという転送上の事実を示す。発行権限の証明ではない。
  • RFC 10003 の各バインディングは交換の境界を明確にするが、CA の決定をネットワーク上に移植しない。

TLS 1.3 や QUIC で CMC の HTTP リクエストに 0-RTT を使ってはならない。RFC 10003 が挙げる理由は単純で、POST は冪等ではないからだ。同じ早期データが再実行されれば、同じ要求を一度だけ扱うという運用上の前提が崩れうる。この一文は実装者にとって重要である。しかし、そこから「安全な接続なので権限も確認された」と読むことはできない。

この対比は CMC の役割をよく示している。RFC 10003 は、証明書管理メッセージをどのように運ぶかを定義する。HTTP ではクライアントが POST を送り、サーバーの 2XX が転送処理の成功を表す。TCP ではバイナリの CMC メッセージを直接運び、クライアントは同一接続で次の要求を送る前に完全な応答を待つ。ファイルとメールにも、それぞれ一つの対象を扱うための形式がある。

これらの記述が確定させるのは、オブジェクトがどの経路で提示され、相手がどこまでプロトコル交換を完了させたかである。確定させないのは、受信側がどの組織の CA として行動したか、要求者の資格がどの規則で確認されたか、ある変更が許可されたか、そして証明書が発行されたかである。応答が戻ることと、意思決定が成立することの間には、故意に残された距離がある。

HTTP バインディングは HTTP 認証や cookies を必須にしていない。これは欠落ではなく、転送プロファイルが包含しない責任の範囲を示している。環境に応じて再生攻撃への防御が必要になりうることも記されている。接続の保護、再送の抑制、メッセージの完全性はどれも有用だが、それらを組み合わせても地方の組織的な権限構造が自動で生まれるわけではない。

メール経路では、限界がさらに見えやすい。最初の SMTP ホップで TLS が使われていても、その後のホップの認証や暗号化は保証されない。CMS や S/MIME によって内容を保護することはできるが、内容を秘匿できることと、内容に法的・運用上の効果を与える権限があることは別である。封筒は決裁印ではない。

運用記録には二つの時間軸が必要になる。一つは、メッセージがいつ、どのバインディングで移動し、どの応答が戻ったかという通信の時間軸。もう一つは、どの主体がどのポリシーで判断し、何を発行または拒否したかという決定の時間軸だ。前者だけを高速にして後者を省略すると、監査可能性はむしろ薄くなる。