要約

  • RFC 9934 の PEM ファイルは、ゼロ個または一個の PKCS #8 秘密鍵と一個の ECHConfigList を持つ。秘密鍵があれば、リスト内の公開設定の一つと対応しなければならない。
  • その一致はローカル制約であり、サーバーが読んだ世代、DNS の公開値、クライアントのキャッシュ、ECH の受理、通信先秘匿の結果までは証明しない。

運用会議で「どの鍵が新しいか」と尋ねても、答えは一つではない。鍵管理システムの最新版、ディスク上の最新版、プロセスが保持する最新版、DNS が返す最新版、端末が記憶する最新版がある。RFC 9934 が整えるのは、そのうちファイルという受け渡し面である。

RFC 9934 は異なる TLS 実装が ECH 用材料を扱える共通形式を定めた。一つのファイルには秘密鍵がゼロ個または一個あり、その後ろに一つの ECHConfigList が続く。秘密鍵は PKCS #8 PrivateKey で、区切りは PRIVATE KEY。公開リストは base64 で表現され、区切りは ECHCONFIG である。秘密鍵が入る場合、リスト中の少なくとも一つの ECHConfig と公開鍵が一致する必要がある。

これは「ファイルとして何を受け渡したか」を強くする規則だ。プロセスが再読込したか、複数ファイルのどれを採用したか、どのリストを retry_configs に使うかは別である。リストは異なる拡張や public_name を持つ複数設定を優先順に格納できる。一つの鍵との一致を、全メンバーの稼働能力へ拡張してはならない。

秘密鍵ゼロ個という許容も重要である。DNS に公開してよいのは ECHConfigList だけで、秘密鍵は公開してはならない。秘密を含むサーバー用投影と、発見に使う公開投影は意図的に非対称だ。安全な自動化は同じ世代識別子で両者を結びながら、権限と配送経路を分離する必要がある。

RFC 7468 のテキスト境界は、実装ごとの差を減らす。ただし、ラベルが正しく base64 を復元できても、秘密の保管者やロード済み状態は分からない。実務上の支配者には、ファイル所有者以外にバックアップ、スナップショット、配布エージェント、保守経路も含まれる。

RFC 9849 では、クライアント向けサーバーは現行の公開設定だけでなく、DNS TTL 以上にキャッシュされ得る過去設定も保持することが推奨される。復号できれば内側 ClientHello を使い、ECH を受理できる。復号できなければ外側で処理し、ECH を拒否して新しい再試行設定を返せる。拒否された接続は、そのままアプリケーションデータ用にはできない。

従ってローテーションは重なりを持つ移行である。新秘密の作成、ファイル配置、ロード、権威 DNS 更新、再帰キャッシュ失効、端末再試行を順序づける。旧鍵をすぐ消すと正当なキャッシュ利用者を拒否する。永久に残せば秘密の閲覧面と試行復号の負担が増える。

監査記録には秘密でない世代 ID、ファイルハッシュ、ブロック数と順序、鍵対応、実際の読取主体、配布とロードの受領、サーバー既知集合、権威 RRSet、複数キャッシュの値と年齢、クライアントの config_id、受理・拒否、再試行設定、証明書検証、Finished、アプリケーション観測を別々に残す。秘密鍵そのものは記録へ複製しない。

RFC 9848 は、DNS に ech があってもプライバシー全体が完成しないことを示す。ECH 有無を混在させた宛先は選択的遮断でダウングレードし得る。平文 DNS、IP、トラフィック特徴、小さな匿名集合も情報を残す。RFC 9460 のサービス束縛は秘密鍵状態を監視しない。

Heng Lu の Running-Code Primacy を適用すれば、各実行主体の証言範囲が明確になる。パーサーは読んだバイト、サーバーはロード集合、DNS は公開値、クライアントは交渉、アプリケーションは結果を語る。どれか一つを全体の代弁者にしないことが、証拠設計の中心である。

情報源