要約

  • 9月28日、IETF は Key Transparency Architecture を AD Evaluation::Revised I-D Needed に変更し、ラベル所有者と、そのラベルを信頼判断に使う依存当事者を分けるよう求めた。
  • 検索証明やツリーヘッド署名が正しくても、誰が値を変更できたか、どのアクセス判断が検索を許可したか、誰が後続監視を担うかは自動的には決まらない。
  • 運用には、所有者、要求者の役割、認可判断、配備モード、署名者、時間条件、以前の状態、未完了の監視義務を結び付けた検証レシートが必要になる。

暗号ライブラリは成功を返す。検索証明は検証され、ツリーヘッドの署名は正しく、新しい応答はクライアントが保存していた以前のビューに連なる。計算上の異常はない。

ところが、運用上の問いはそこから始まる。検索した主体はラベルの所有者なのか、他人の公開鍵に依存する当事者なのか。開示を許可したポリシーはどれか。値を変更できたのは誰か。新しく見えたバージョンが所有者の確認前に消されなかったことを、後日確かめる責任は誰にあるのか。valid=true は、そのどれも示さない。

2026年9月28日、IETF セキュリティ領域ディレクターの Deb Cooley は、第09版 Key Transparency Architecture へのレビューコメントを公開した。Datatracker の履歴には、状態が AD Evaluation から AD Evaluation::Revised I-D Needed に変わり、著者 Brendan McMillion が対応者になったことが記録されている。文書は情報提供 RFC を目指す Internet-Draft のままであり、RFC の成立や実装の存在を意味しない。

レビューの核心は、用語の修正に見える。第09版は User / Account を定義する一方、後段ではラベル所有者と、別人のラベルを検索する「ユーザー」に異なる仕事を割り当てる。Cooley は所有者と relying party を分けるよう提案した。前者はディレクトリ結合の対象であり、後者はその結合を根拠に相手を信頼する。権利も損失も後続作業も同じではない。

鍵透明性が対象とするのは、エンドツーエンド暗号化の入口である。サービス運営者は通信に必要な公開鍵を配ることが多い。攻撃者が秘密鍵を持つ別の公開鍵をアカウントへ結び付ければ、暗号化処理そのものは成功しながら、誤った相手を保護できる。そこでアーキテクチャは、ID と公開鍵の対応を暗号学的に保護された追記専用ログへ置く。Search、Update、Monitor は証明を返し、以後の応答はクライアントが以前に見たビューと整合しなければならない。

分岐は永続化されても、自動では発見されない。文書は、信頼する第三者、匿名経路からの照会、または端末間比較のいずれかを別途求める。第三者方式では、その組織が最新ツリーヘッドへ署名し、利用者はログと共謀しないことも信頼する。匿名・端末間方式ではクライアント自身が矛盾を探す。証明は継続観測の一部であり、一回限りの誠実性証明書ではない。

三つの配備モードは、この観測責任を別々に配置する。

Contact Monitoring では第三者を置かない。所有者は最新のラベル値に不審な変更がないか定期的に調べ、直近のバージョンを検索した依存当事者は、それが所有者に見つかる前に隠されなかったか後で再確認する。重要なのは、元の Search や Update が現在のポリシーでは許されなくなっても、必要な Monitor は許可しなければならない点だ。現在のアクセス失効は、過去の正当な観測から生じた証拠義務を消さない。

Third-Party Auditing では、ログが主な保存と運用を続け、監査者が定期的にツリーのビューへ署名する。証拠の意味は、監査開始位置と許容される最大遅延に左右される。真正な署名でも、意思決定に対して古すぎることがある。

Third-Party Management では、外部管理者が保存と運用の大半を担う一方、サービス運営者がアクセス制御と新しいラベル版の認証を担当する。安全性は両者が共謀しないという前提に立つ。レビューは図6に正当な検索を加えるよう求めた。Alice が自分の項目を検索・更新する流れだけでは、他人の鍵を必要とする依存当事者の経路が見えないからだ。

第05版 Key Transparency Protocol は、モードを監査記録から落とせない理由を具体化する。設定には配備モード、署名鍵、VRF 公開鍵、合理的監視期間が入り、監査方式では監査者鍵、開始位置、最大遅延も入る。運営者の署名、管理者方式の署名、遅延条件付き監査署名は、すべて検証できても同じ信頼を表さない。

クライアントの保存状態も安全性の主体である。以前のビューが次の応答を拘束するため、その状態を失えば分岐や後日の隠蔽を見抜く力が落ちる。ウェブページのように状態が一時的な場合や、攻撃者が消去を誘発できる場合、第09版は第三者管理を推奨する。レビューは、状態喪失の例と、「永続的な無効状態」を検出するため利用者が有限時間オンラインである必要があるという記述の整理を求めた。

アクセス制御はアプリケーション側に残る。連絡先だけに検索を許す、ログインを求める、回数を制限するといった判断はログ構造の外側だ。証明はログが要求をどう処理したかを示すが、この要求者への開示が正当だったとは示さない。レビューが「友人」と「アクセス制御」の混在を ACL 用語へ揃えるよう求めるのは、そのためである。

プライバシーと削除には別の時間軸がある。期限切れ、または恒久的にアクセス不能になった利用者データは削除できても、検証に必要な暗号材料は最大存続期間まで残る場合がある。ラベルの秘匿には検証可能ランダム関数が使われる。レビューは、設計理解に VRF が必須なら RFC 9381 を規範参照へ移し、プライバシー節を整理するよう促した。

文書間依存も対象になった。shepherd の報告はアーキテクチャをプロトコルの基盤と位置付ける。アーキテクチャを先に公開するなら、プロトコルへの参照は例示に留める必要がある。また、Certificate Transparency の比較で、後継 RFC 9162 だけでなく、実装されている RFC 6962 を使う理由も説明するよう求めた。MLS は匿名グループの資格情報を説明する背景であり、KT の配備証拠ではない。

運用上必要なのは新しいハッシュではなく、役割付き検証レシートである。証明とラベル版に加え、要求者が所有者か依存当事者か、認可ポリシーと版、配備モード、署名主体、ツリーサイズと時刻、許容遅延、整合性判定に使った以前の状態、将来必要な Monitor を残す。

そうすれば、証明自体の失敗、正しく証明された不正な開示、古い監査ビュー、未実施の監視、状態を失ったクライアントを分けて扱える。第10版が別の解決を選んでも、境界は変わらない。追記専用履歴は欺きを発見可能にする。役割の明示だけが、発見する責任者を決める。

情報源