Summary

  • KEYTRANS の検索証明は、許可された問い合わせへの応答と認証済みログ状態を検証できる。しかし、問い合わせがログへ到達する前の許可・拒否判断は証明の対象外である。
  • 現行アーキテクチャ草案は、認証、関係性、所有権、レート制限など、アプリケーション固有のアクセス制御を広く認める。これは存在情報の保護に必要だが、重要な決定を不可視にもする。
  • Daniel Kade は、方針版、操作種別、要求者・関係の分類、判断コード、ログ時期、例外と訂正を残しつつ、氏名、生ラベル、公開鍵、連絡先グラフ、完全な検索履歴を残さない「検索方針レシート」を提案する。これは編集上の提案であり、IETF の要件ではない。

正しい証明の前に、見えない選別がある

Alice が Bob の鍵を検索し、KEYTRANS の SearchResponse と有効な証明を受け取る。前置木の経路も、追記型ログの整合性も検証できた。Alice が見た対応関係は、認証された状態に含まれている。ここまでは透明性の成功例だ。

同じ Bob を Fred が検索すると、アプリケーションは必要な関係がないとしてトランスポート層で止める。Fred に偽の証明が渡されたのではない。透明性プロトコルの操作そのものが始まらない。ログだけを監査すれば、Alice の成功は見えるが、Fred の拒否が正当だったかは判定できない。

この違いは実装の細部ではない。どの主張を暗号学的に証明し、どの判断を組織の裁量として残すかという統治境界である。木のルートが真正でも、門番の方針が一貫しているとは証明されない。

KEYTRANS が守ろうとしているもの

エンドツーエンド暗号化では、利用者の公開鍵を配るサービスが別の鍵へ差し替えれば、暗号化されているように見える会話へ介入できる。KEYTRANS は、ラベルと値の対応を検索可能な前置木に置き、その状態遷移を追記型ログで認証することで、この配布点を検証可能にしようとする。

正しく検証された証明と継続監視は、返された値が承認された木に属するか、ログが一貫した履歴をたどったか、利用者ごとに矛盾する表示が与えられていないかを確かめる助けになる。RFC 6962 と RFC 9162 の証明書透明性は、追記型構造と整合性証明が隠れた改変の発見に役立つ先例を与える。

ただし、draft-ietf-keytrans-architecture-09 は Informational を想定した作業中の Internet-Draft であり、draft-ietf-keytrans-protocol-05 も完成した RFC ではない。採択された KEYTRANS 憲章は作業範囲を示すが、特定サービスへの導入や市場での採用を示すものではない。

草案は、KEYTRANS が単独で動く標準ではなく、サービスへの統合を必要とすると明記する。プロトコルは格納された対応関係と履歴を認証する。誰が Search、Update、Monitor を実行できるかは周辺アプリケーションが決める。この分担を無視すると、応答の証明を入口の公正さの証明へと過大解釈してしまう。

拒否はプライバシー機能でもある

全員に全ラベルの検索を許せばよい、という解決は成立しない。ある人物がサービスに登録しているか、特定組織の一員か、ある保護対象グループと関係があるかという存在情報だけでも、重大なプライバシー漏えいになり得る。RFC 6973 と RFC 7258 が扱う脅威を考えれば、最大の可観測性は最大の安全性ではない。

そのため KEYTRANS の現行憲章は、身元の存在やアカウント情報を、問い合わせる権限のあるクライアントにだけ示すという方向を採る。アーキテクチャは、既存の認証、所有権、「友人」関係、組織内関係、レート制限などを再利用できる。プロトコルが多様なサービスの社会的意味を一つに標準化しないのは合理的だ。

しかし合理的な裁量にも説明責任は要る。正当な匿名性保護、短期の不正対策、期限切れの緊急例外、商業上の差別的取扱い、単純な障害は、すべて「ログに検索がない」という同じ外形になり得る。成功した操作だけが証拠を残すなら、制度的に異なる出来事を区別できない。

権限失効は時間を含む

Contact Monitoring の設計は、許可が瞬間的な二値ではないことを示す。クライアントが過去に相手を検索したなら、新しい Search や Update の権限を失った後も、以前の版に関する Monitor を継続する必要がある場合がある。草案は限定的な継続経路を設け、コミットメントの開示によって過去の権限を示す方法も扱う。

これはセキュリティ上の意味を持つ。権限を失った瞬間に監視まで切れば、既存会話に関係する鍵の不正変更を検出できなくなるかもしれない。一方、失効後も新しい情報を無制限に読めるなら、プライバシー上の失効が空洞化する。RFC 9420、RFC 9458、RFC 9614 が示すメッセージ層の考え方でも、安全性は時系列の状態とメンバー変化に依存する。

監査記録は「今は拒否」という一行では足りない。どの方針版で Search が失効し、どの過去状態に対する Monitor が残り、いつその義務が終わるのかを区別しなければならない。入口の判断は、単純な門ではなく状態機械なのである。

第三者が見ても、入口全体は見えない

第三者管理の構成では、サービス運営者がアクセスを制御し、管理者は受理された平文ラベル、値、履歴、検索トラフィックを見得る。だが運営者が入口で拒んだ要求は、管理者へ届かない可能性がある。管理者が自分の処理を正しく行っても、見えなかった母集団の完全性は証明できない。

第三者監査の構成は別の視野を与える。監査者は変更の数、順序、時刻を観測できる一方、ラベルや値は隠される。これは機密性には有利だが、ログの前で拒否された要求を自然に数える仕組みではない。ログ監査者、管理者、サービス運営者は、互いに異なる切片を見る。

同一の支配主体が複数サービスを運営する場合、アーキテクチャはプロキシによる匿名化も想定し、方針へ干渉するログの鏡像化や統合を避けるよう注意する。つまり、監査のために全サービスの検索・拒否履歴を中央へ集約する案は、KEYTRANS が避けようとする相関リスクを再び作る。

検索方針レシートという狭い証拠

必要なのは公開の検索台帳ではなく、方針判断だけを最小限に証明するレシートだ。アプリケーションが許可または拒否を決めた時点で生成し、適用された方針版に結び付け、権限を持つ監査者が限定された問いを検証できるようにする。

レシートには、Search・Update・Monitor の操作分類、粗い要求者分類、関係分類、回転鍵で作る対象ダイジェスト、判断コード、関連ログ時期、規則または証拠の分類、例外承認者と期限、訂正状態、保持期限、集計テスト識別子を含められる。対象ダイジェストを定期的に変え、分類粒度を抑えれば、長期間の連絡先グラフ再構成を難しくできる。

逆に、利用者名、生のラベル、公開鍵、認証情報、メッセージ、完全な IP アドレス、恒久的な機器 ID、平文の関係、個人の完全な検索履歴は含めるべきでない。実装には脅威モデル、鍵分離、アクセス権、保持・削除規則が必要で、単にログを増やすことが目的ではない。

監査者が答えるべき問いは狭い。同じ方針版で同じ分類の要求が一貫して扱われたか。期限切れの例外が使われていないか。失効後に必要な Monitor が維持されたか。誤判定の訂正が実行されたか。個人が誰を検索したかを公開せずに、この水準の検査は設計できる。

ただしレシートを透明ログへコミットしただけで完全性が保証されるわけではない。記録されなかった判断の存在を、記録済みハッシュから証明することはできない。入口件数との照合、制約付き実行、独立サンプリング、欠番検査など、被覆範囲を確かめる別の仕組みが要る。

削除と監査は対立だけではない

アーキテクチャは、アプリケーション方針によって永久にアクセス不能となった値を削除できることと、プロトコルが必要とする暗号材料を分けて扱う。ログはアクセス方針そのものを理解しない。削除の根拠、例外、既存 Monitor との関係はアプリケーション側の責任である。

方針レシートも永久記録であってはならない。短い保持期間、回転するダイジェスト、集計化、限定アクセス、訂正連鎖を組み合わせれば、決定の検査可能性を残しながら、将来の運営者や攻撃者が過去の社会関係を復元する価値を下げられる。監査可能性は、データを無期限にためることと同義ではない。

証拠が語らないこと

参照資料には、特定企業が草案を導入したという証拠も、実際の拒否率、誤判定、差別的運用、事件数、性能、法的適合性のデータもない。本稿は既存サービスの不正を告発するものではなく、作業中の設計から導入実績を推測しない。

アーキテクチャ第 09 版は 2026 年 6 月 30 日付で、2027 年 1 月 1 日に失効予定の作業文書である。プロトコル第 05 版も変更され得る。憲章は作業部会の任務を定めるが、最終仕様や採用を保証しない。

確実に言えるのは限定的だ。KEYTRANS は、許可された検索の応答を検証可能にする。しかし、誰の検索を許すかという方針の一貫性、例外、訂正を自動では証明しない。プライバシーの門を残しながら、その門を無責任な暗部にしないための証拠設計が必要である。

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-09
  5. https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/
  6. https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/history/
  7. https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-protocol-05
  8. https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/
  9. https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/history/
  10. https://datatracker.ietf.org/doc/charter-ietf-keytrans/
  11. https://www.rfc-editor.org/rfc/rfc6962.html
  12. https://www.rfc-editor.org/rfc/rfc9162.html
  13. https://www.rfc-editor.org/rfc/rfc6973.html
  14. https://www.rfc-editor.org/rfc/rfc7258.html
  15. https://www.rfc-editor.org/rfc/rfc9420.html
  16. https://www.rfc-editor.org/rfc/rfc9458.html
  17. https://www.rfc-editor.org/rfc/rfc9614.html