要約

  • 9月28日付の個人提出草案は、後年の証拠として残すエージェント委任には、署名鍵から信頼の起点までの経路と、独立した時刻の裏付けを伴わせるべきだと提案する。
  • 耐量子移行の要件は提案段階であり、IETFが採用した義務ではない。量子計算機による攻撃や、現在のOAuth通信の破綻を報告した文書でもない。

外部のツールを呼び出すエージェントについて、サービスが発行者の鍵集合をTLS経由で取得し、委任トークンの署名を検証する。現在のアクセス判断としては筋が通る。しかし記録を長く保管する場合、問いが変わる。数年後にトークンと公開鍵だけを渡された監査人は、鍵集合を取得したときにどの証明書連鎖がサーバーを認証したか、その連鎖がどのアルゴリズムに依存していたかを確かめられるだろうか。署名の計算結果は、その通信の履歴までは語らない。

V. K. Uppalapatiが28日に提出した Post-Quantum Requirements for Software and AI Agent Identity 第00版は、この保存上の空白を起点とする。Datatracker上の状態は I-D Exists。Informationalを目指す個人草案であり、WIMSE作業部会の採択文書でもRFCでもない。著者は、TLSで取得したOAuthの鍵集合と信頼の起点を結ぶ情報を、エージェント委任の証拠に添えて保存する一般的な要件がないと論じる。ただしこれは著者による仕様調査の判断で、あらゆる実装が同じ情報を捨てているという実測ではない。

草案は、稼働中のTLS認証を無価値とはしていない。接続したクライアントは、その時点で鍵集合の配布元を認証できる。問題は接続を閉じた後、別組織の人が同じ根拠を再検証できるかにある。保管者が鍵集合と通信で見た証明書を一緒に残しても、第三者は「本当にこの組み合わせだったのか」という保管者の説明を信じる必要がある。鍵との結び付きを別途署名して独立に検証できれば、証拠の性質が変わる。発行者が自分の鍵について自己申告するだけでは、証明すべき結び付きを前提にしてしまう。

もう一つは時刻である。署名は適切な検証経路の下で使用された鍵を示すが、いつ署名されたかを単独で確定しない。RFC 3161のタイムスタンプはデータのハッシュがある時刻以前に存在したことを示す材料となり、RFC 4998は長期保存の証拠を、使われるアルゴリズムや証明書が弱くなる前に更新する仕組みを述べる。ただしタイムスタンプ自体も署名されている。新草案が求めるのは、早期の時刻固定と、まだ決まっていない移行日以後の耐量子的な裏付け、そして継続的な更新だ。量子計算機による解読が既に起きたとの主張ではない。

末端のエージェント証明書だけを新方式にしても、起点が従来方式のままなら経路全体の保証にはならない、というのが草案のもう一つの論点だ。従来のWeb PKIだけに支えられたOAuth鍵の取得にも、長期証拠という観点では同じ問いが残る。末端の交換は移行の準備にはなるが、取得当時の鍵の来歴や時刻を後から生成することはできない。各段階のアルゴリズムを検証者に見せ、記録とともに保持するという提案が、今後どの仕様にどの形で入るかは未定である。

なお発行者の署名は、人がある操作を承認したことそのものの証明ではない。発行者が何を主張したか、委任した主体は誰か、受け手の方針は何か、記録はいつ存在したかを区別する必要がある。今回のニュースは「署名さえあれば権限は証明済み」という単純な話ではなく、即時の判断に使った鍵の根拠を長期証拠へ運ぶ設計の不足にある。

出典