要約

  • 9月28日付の draft-reddy-wimse-aggregate-signatures-01 は、活動中の個人提出Internet-Draftであり、WIMSE作業部会の採択文書でもRFCでもない。
  • 各段階の受信・送信ダイジェストは、内容を書き換えた中継者が取り除かれた場合には食い違う。一方、無変更で転送した者は、ダイジェストだけでは消され得る。
  • 提案する集約署名は後者の参加を検証するためのものだが、認可や無変更の中継者同士の順序、最終処理の成否までは証明しない。

三つのワークロードが依頼を受け渡す場面を考える。二番目は依頼を受け、署名し、一文字も変えずに三番目へ送る。二番目の独立した署名だけを記録から外しても、一番目の出力と三番目の入力のダイジェストは一致する。内容のつながりは成立したまま、経由した主体が一つ欠ける。新しい草案の付録Aが示すのは、この見落としである。

文書名は Authenticated Provenance for WIMSE Delegation Chains。IETF Datatrackerでは、9月28日付の第-01版を活動中の個人Internet-Draftとし、RFC streamを割り当てず、IESGの状態を I-D Exists と表示している。提出された文書にIETFの承認はない。第-00版にも集約署名の構想は存在したため、第-01版が発明したと書くべきではない。今回の改訂は、誰が内容を変更したかと、変更せずに経由したかをより明確に切り分け、パス・クエリーや応答側の扱いも詳しくした。

基礎となるWIMSEのHTTPメッセージ署名は、送信側ワークロードを直後の受信側に対して認証する。一対一の交換を守る仕組みから、最終受信者が委任経路全体の参加者を知れるわけではない。個人提案は各署名者に、受け取った本文と送った本文のダイジェスト、パスやクエリーの値を残させる。内容を書き換えた者を抜き去れば前後の記録がつながらない。変更箇所の特定には役立つが、その変更が正しい判断だったか、記述が事実かまでは示さない。

無変更の転送者を扱うため、提案は各段階の署名を一つの Signature-Aggregate に加える。個別の署名をそのまま経路へ流さず、提示された署名者とメッセージの集合に対して集約値を検証する。草案の暗号学的前提の下では、一度署名した転送者を一覧から消すと検証が通らないという設計である。これは仕様案の主張であり、実装や運用の検証結果ではない。

運用上の制約も残る。集約署名そのものがほぼ一つ分の大きさでも、ワークロードの資格情報、署名入力、各段階のダイジェストは経路に応じて増える。全段階に互換性のある集約可能な方式が要る。草案はML-DSAには集約がなく、個別署名への退避では無変更の転送者を消す攻撃を防げないと説明する。一つの不正な署名で全体の検証が失敗し、どこが原因か直ちには分からない。連続する無変更の転送者の順序も、内容の履歴だけでは認証されない。HTTPフィールドなどはIANAへの登録提案で、登録済みの事実ではない。

さらに草案は認可を対象外と明記する。署名の検証は、そのワークロードが依頼を扱う権限を持っていたことも、最終的な操作が成功したことも意味しない。参加者の証拠を、権限判断にすり替えてはならない。

出典