要約

  • draft-ietf-keytrans-architecture-09のトゥームストーンは、旧ログから新ログへラベル検索を切り替え、到達不能な新ログの代わりに古い値が復活するのを防ぐ。
  • 同じ文書は、新旧両ログを別々に監視し、長くオフラインだった利用者も旧ログの監視を完了できる期間、旧ログを稼働させるよう求めている。
  • 廃止判断には、旧ログの最終ツリーヘッド、配布経路、端末群ごとの完了証拠、例外、決裁者、復旧条件を結ぶ「ログ廃止受領書」が必要だ。これは本稿の提案であり、IETF案の要求ではない。

端末の引き出しから、半年ぶりにスマートフォンが戻ってくる。アプリはすでに新しいKey Transparencyログへ移行し、旧ログには各ラベルのトゥームストーンが書かれている。運用画面の移行率はほぼ百パーセント。旧エンドポイントは先月停止した。しかし、その端末だけは移行前に保存したツリーヘッドを持っている。

新しい検索先を知ることはできても、保存済み状態から旧ログの最終状態までをつなぐMonitor処理はできない。アーキテクチャ案が警告する通り、利用者の監視完了前に旧ログを止めれば、その利用者は旧ログによる一部の不正を検出できなくなる。

ここで分かれるのは「データ移行」と「検証可能な歴史の閉鎖」である。トゥームストーンは前者の経路を整えるが、後者を証明しない。

古い値を生き返らせない仕組み

エンドツーエンド暗号化でも、アカウントと公開鍵の対応をサービス事業者だけが配るなら、事業者の侵害や不正による鍵の差し替え余地が残る。Key Transparencyは、検索可能で暗号学的に保護された追記型ログを使い、利用者同士が同じ対応関係を見ているか継続確認できるようにする。

KEYTRANSの憲章は、この仕組みを完全なメッセージサービスではなく構成要素と位置づける。認証、アカウント復旧、端末寿命、サポート期間まで標準化するものではない。この節度は、移行時の責任を考えるうえで欠かせない。

ログ移行には正当な理由がある。署名鍵や暗号スイートの変更、配備方式の変更、容量拡張、障害復旧である。アーキテクチャ案は、クライアントが複数の独立ログを扱えるよう備えるべきだとする。同時に、Search、Update、Monitorをどのログに向けるかについて、全利用者が一貫した方針を共有しなければならない。

段階移行の例では、Searchはまず旧ログへ行く。そのラベルの最新版がアプリケーション定義のトゥームストーンなら、新ログを検索する。通常のUpdateは新ログだけに書き、旧ログには必要に応じてトゥームストーンを加える。この順序により、新ログの障害を口実に移行前の鍵を受け入れることができなくなる。

ただし、トゥームストーンが示すのは最新値の所在である。移された値の正しさ、所有者による確認、全端末への到達、旧ログ停止の妥当性までは示さない。

二つのログには二つの監視責任が残る

文書は、新旧両方のログを、それぞれ単独運用されている場合と同様に監視するよう述べる。新しいUpdateの行き先を変えた瞬間に、古い歴史の責任まで消えるわけではない。

旧ログは、明示した時点で変更受付を止め、最終状態を固定する必要がある。各クライアントは手元の過去状態からそこまでの整合性を確かめる。新ログでは、移行したラベル版を所有者が確認し、新たな監視状態を築く。第三者監査、第三者管理、匿名照会、利用者間のゴシップのどれを採るかによって、非共謀や確認頻度の前提も変わる。

だから「最新版アプリの導入率」は完了証明にならない。導入済みでも起動していない端末がある。新ログへ接続しても自分のラベルを検証していない場合がある。主端末が済んでも古いバックアップが後日復元される。休眠アカウントは、権利放棄と同義ではない。

案は一律の日数を指定しない。旧ログを全利用者が監視完了できるだけ長く維持し、長期間オフラインの利用者を考慮せよと述べる。企業向けの高リスク通信と、一般消費者向けサービスと、一時状態しか持たないWebクライアントでは、想定すべき復帰期間が違う。日数を共通仕様に固定すると、各事業者の約束を技術定数に見せかけることになる。

最終ツリーヘッドは共通の終点にすぎない

即時移行の例では、旧ログの最終ツリーサイズとルートハッシュを信頼できる経路で利用者へ配る。利用者はその地点まで最後のMonitor照会を行う。ラベル所有者は、新ログに移された版についてUpdateを処理し、移行が正しいか確認して監視を開始する。

配布方法として、旧ログの最終座標を新ログのwell-knownラベルに格納する案と、アプリのコード配布経路に含める案が示される。どちらも共通終点を与えるが、誰が終点を選んだか、対応対象の全版へ届いたか、さらに古い状態を持つ端末をどう扱うかは別問題である。

プロトコル案にはmax_ahead、max_behind、reasonable_monitoring_window、任意のmaximum_lifetimeが設定値として入る。合理的監視期間は、所有者が通常どれほどの頻度でラベルを監視するかを表し、共通の検査地点を作る。実際の端末人口を数える値ではない。最大寿命も、保存容量を制御できるが、利用者サポートの約束を自動決定しない。

ログ廃止受領書に残すもの

個人名や鍵、私的な監視履歴を公開する必要はない。必要なのは、停止判断を後から検証できる最小限の記録である。

旧ログの境界。 設定、署名主体、変更受付終了、最終ツリーサイズとルート、時刻、配備方式、直前の公知ヘッドとの整合性証明を記録する。

移行規則。 新旧ログの識別子、Search・Update・Monitorの振り分け、トゥームストーンの意味、それを実装するクライアント版を固定する。「検索先変更」と「旧証拠の廃棄」を別項目にする。

配布の証拠。 コード更新、well-knownラベル、管理端末ポリシーなど、最終ヘッドを運んだ信頼経路を列挙する。総ダウンロード数ではなく、対応版・OS・休眠期間ごとに到達を測る。

完了条件。 新ログ接続、移行ラベル確認、旧ログ最終監視、バックアップ復元試験を別々に記録する。一つの成功を四つの成功として数えない。

オフライン例外。 対応する最長復帰期間、再インストール、多端末、古いバックアップ、アクセス不能アカウントの扱いを明示し、推計と実測を分ける。

権限と復旧。 暗号学的閉鎖を確認する責任者、可用性リスクを受け入れる責任者、データ保持境界を決める責任者、最終停止の決裁者を記す。矛盾したヘッドや橋渡し不能な端末が出た場合の延期・復旧条件も定める。

文書の状態を誇張しない

第09版アーキテクチャはIESGへの出版要求段階にあるInternet-Draftで、想定はInformationalである。RFCではない。シェパードレビューは、比較的小規模な専門家集団から合意と貢献があり、重大な反対がなかったと記録する。これは成熟度の証拠だが、最終標準や商用配備を証明しない。

一方、IETF 126の議事録には、以前のUpdateRequest形式が実装不能だったため新形式を検討したこと、現在の転送形式の自由度が相互運用性を損ね得るという実装者の指摘が残る。発言は合意文書ではない。それでも、アーキテクチャ上の約束、プロトコル版、動く実装、事業者の廃止決定を一列に潰さない理由になる。

共同層が守るべき最小条件は二つある。新ログが読めないときに古い鍵を復活させないこと。旧履歴を閉じる合理的機会を利用者から奪わないこと。その機会を何日、どの端末に約束するかは、名前のある決裁者が引き受けるべきで、トゥームストーンに任せるべきではない。

出典

  1. KEYTRANS Architecture 第09版
  2. 文書履歴とシェパードレビュー
  3. KEYTRANS Protocol 第05版
  4. KEYTRANSワーキンググループ憲章
  5. IETF 126 KEYTRANS議事録
  6. Lu Heng「Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption」
  7. Lu Heng「Running Code Primary」