要約

  • draft-mcewan-adkm-problem-statement-00 は、外部発行者による各遷移の再承認や単一の世界的合意基盤を必須とせず、安定した識別子の鍵状態を検証可能に進化させる相互運用上の空白を整理する。
  • 重要なのは、日常処理に有効な現行署名鍵と、任意の将来状態を確立する権限を同一視しないことだ。現行鍵の侵害に耐えるには、その鍵だけでは後継状態を決められない設計が必要になり得る。
  • 履歴の暗号学的妥当性、十分な鮮度、競合履歴の観測、復旧権限、アプリケーションの判断、実際の結果は別々に記録しなければならない。

事故対応会議で「新しい鍵への切替は正常に署名されています」と報告されたとする。署名者は旧鍵、対象は新鍵、イベント番号は連続し、正規化されたバイト列も一致している。

それでも承認を止める理由はある。旧鍵が侵害対象だったなら、その署名は「正当な管理者が復旧した」証拠であると同時に、「攻撃者が後継鍵を登録した」証拠にもなり得るからだ。暗号はどちらが署名したかを示す。署名者がこの種類の未来を決める権限まで持っていたかは、別の規則が決める。

2026年9月20日付の個人Internet-Draft「Autonomous Decentralized Key Management Problem Statement」は、この区別を解決済みの方式ではなく問題領域として提示する。安定した識別子が通常のローテーション、緊急交換、しきい値変更、委任、復旧、失効をまたいで存続し、依拠者が認証済みイベント履歴を検証できるために何が必要かを問う。イベント形式も、保存方式も、観測者も、台帳も選んでいない。

署名権限と継承権限

草案の Key State は単一の公開鍵ではない。公開鍵群、署名しきい値、役割、その他の認可パラメータの集合である。Key Event はその状態を確立または変更する認証済みの声明であり、Controller は現状態とプロトコル規則が許す遷移だけを承認する。

この構造を運用に落とすと、同じ鍵がすべてをできる必要はない。アプリの要求には単独で署名できても、しきい値を下げるには復旧役割が必要かもしれない。限定的な委任はできても、他の全Controllerを削除してはならないかもしれない。自分を失効させることはできても、無制限の後継者を単独で指名できないかもしれない。

証拠 確認できること それだけでは確認できないこと
現行鍵の署名 指定バイト列をその鍵が署名した この遷移クラスに必要な権限を満たした
遷移ポリシー 適用された役割・しきい値・版 入力が新しく、鍵が未侵害である
連結履歴 提示状態が許可された遷移をたどる それが最新かつ唯一である
復旧承認 分離された復旧能力が参加した 復旧能力の独立性が保たれている
整合性証拠 確認範囲で競合が観測されたか 未観測の分岐が世界に存在しない
アプリ判断 特定操作にローカル規則が許可した 現実の操作が成功した

オフライン検証の価値と限界

Local Evidence Verification は、指定された権威へ同期照会せず、手元の暗号学的証拠と規則で提示状態への履歴を検証する能力だ。通信が断続的な拠点やエアギャップ環境には重要である。

ただし草案は、その証拠だけでは提示状態が最新だと証明できないと明記する。古い履歴も正しく署名され得る。競合する二つの履歴も、それぞれ内部では正しく見え得る。したがって「履歴が妥当」「用途に十分新しい」「競合が観測されていない」を一つの緑色表示にまとめてはならない。

保守端末が昨日の状態を読むことと、高額取引を今承認することでは鮮度要件が違う。プロトコルは証拠の時刻と範囲を運び、最終的な許容年齢は用途側に残すべきだ。

復旧できない組合せを先に定義する

草案の最も厳しい一文は、すべての秘密と、将来状態の承認に十分な復旧能力を攻撃者が得たなら、どの鍵状態プロトコルも復旧を保証できないという境界だ。

このため設計審査では、単なる「鍵ローテーション対応」ではなく侵害行列が必要になる。運用鍵だけが漏れた場合、一つのしきい値鍵が漏れた場合、運用鍵と一部の復旧分担が漏れた場合、端末全体が支配されたがオフライン復旧が残る場合、すべての承認能力が漏れた場合を区別する。各行について、誰が止められるか、どの観測を待つか、継続性を保てるか、どこからが新しい信頼関係の立上げかを記す。

単一の世界台帳を使わない代償

ADKM は一つのグローバル全順序を必須にしない。これは特定の合意システムの可用性、ガバナンス、finalityから識別子を切り離す一方、equivocationの可能性を残す。悪意あるControllerは、異なる依拠者に異なる有効履歴を見せられるかもしれない。

草案は独立観測者、gossip、相互照合、透明性などを候補として挙げる。RFC 9162 と Key Transparency は、ツリーヘッド、整合性証明、監視、gossipによって不一致を発見可能にする考え方を示す。だが、報告がないことは世界的な唯一性の証明ではない。

観測記録には、観測者、対象コミットメント、時刻、記憶していた前状態、照合相手、ネットワーク分断の可能性を含める必要がある。eclipse、遅延伝播、選択的開示、共謀は、単純な「競合なし」という欄を無意味にする。

PKI、HIP、DIDとの距離

RFC 5280 のPKIXと RFC 6960 のOCSPは、CA、trust anchor、状態サービスを前提とする成熟した行政的信頼モデルである。ADKMはそれを置き換える主張ではない。Certificate Transparency は証明書発行を監査可能にする。RFC 7401 は公開鍵由来の自己証明的Host Identity Tagを示す。DID Core は共通データモデルを定め、更新・復旧・版管理の詳細を各DID methodに委ねる。

ADKMの問いは、これらの隣接部品を否定せず、Controllerが承認する鍵状態の継承をアプリケーション横断で検証できる共通モデルが欠けているか、というものだ。

同じバイト列は同じ権限を意味しない

JCS、CBOR、進行中の dCBOR は、署名対象バイトを一意にするための候補である。正規化がなければ、同じ意味だと思ったイベントが実装ごとに異なるdigestを持つ。

しかし正規化は、誰がしきい値を下げられるかを決めない。鮮度も復旧分担の独立性も証明しない。表現を決定的にすることと、決定を正当化することは別である。

遷移レシートに残す項目

安定識別子とinception binding、前状態digest、sequenceまたはepoch、イベント種別、旧新の鍵・役割・しきい値、適用ポリシー版、各承認の権限クラス、復旧能力の参加、表現profile、イベントdigest、観測者と時刻、競合確認範囲、鮮度源と許容年齢を一つの有界なレシートに残す。

その後、アプリ側が別のdecision receiptを作る。どの状態を、どの操作に、どのローカルポリシーで受け入れ、結果がどうなったかを分離する。鍵状態の真正性はアクセス許可でも成功結果でもない。

この文書の立場

主文書は2026年9月20日公開、Informationalを意図し、2027年3月24日に失効する個人Internet-Draftのrevision 00である。WG採択、IETF合意、実装、導入、相互運用、事故、特定製品の安全性を示すものではない。問題を正確に分解した文書として読むべきである。

出典