要約

  • draft-reddy-wimse-aggregate-signatures-01は、入出力ダイジェストで変換箇所を示し、集約署名で内容を変えなかった署名者の削除も検出する。
  • ほぼ一定サイズになるのは集約署名だけで、WIT、Signature-Input、保存されたパスとクエリ、連続性情報はホップ数に応じて増える。
  • 検証できるのは提示された参加者と変換の帰属であり、期待された全員の参加、変更の許可、処理完了、事業結果ではない。

最終メッセージから過去を作り直す

動的なエージェント連鎖では、起点の依頼と宛先が受け取る要求が同じとは限らない。オーケストレーターが具体化し、ツールが情報を加え、ゲートウェイが別のパスへ送る。宛先に残る最終HTTP表現だけでは、誰が何を受け取り、何を送ったか分からない。

改訂01は二つの証拠を組み合わせる。各ホップは受信した本文のダイジェストをwimse-req-digestに、送信する本文をContent-Digestに記録して署名する。同時に各署名値をSignature-Aggregateへ折り込む。

集約値は連鎖が長くなっても一つの署名に近い大きさを保つ。しかし検証はその値だけに対して行うのではない。検証者は全ホップの公開鍵と署名対象メッセージの組を用意する。公開鍵はWITから、メッセージは各Signature-Inputと保存された値から再構成する。

したがって節10の説明は重要だ。集約署名は小さいままだが、Signature-Input、Workload-Identity-Tokens、ダイジェストは連鎖とともに増える。暗号値の圧縮を、証拠全体の圧縮と呼んではならない。

何もしなかった中継者をどう残すか

H1が本文ダイジェストAを送り、H2がAを受けてAのまま転送し、H3がAをBへ変換したとする。

独立署名とダイジェストだけならH2を削除できる。H1の出力AとH3の入力Aはつながったままで、二つの署名も個別に検証できる。内容を変えなかったことが、存在を消しやすくする。

集約モードではH2の署名寄与が一つの値へ混ざり、個別署名は送信されない。H1とH3だけの連鎖を示すにはH2の寄与を除いた集約が必要だが、その材料がない。提示された鍵・メッセージ集合と集約が合わず、検証は失敗する。

ダイジェストは変換者を抜いたときの不連続を示す。集約は、変換しなかった署名者を抜いた場合も示す。ここが役割分担である。

ただし一度も署名しなかった中継者は見えない。必須サービスが迂回された場合も、宛先が期待経路を別途持たなければ検出できない。特定の審査、フィルター、地域ゲートウェイが必要なら、その条件はポリシーとして定義し、証明済み参加者と照合する必要がある。

古いパスと隣の証言

後続ホップはパスやクエリを書き換える。そこで各送信者は自分の値をwimse-req-pathとwimse-req-queryに残す。H1の署名基を作るとき、最終URIではなくH1の保存値を使う。

H1の送信本文ダイジェストはH2の署名済み入力から得る。最後のホップだけは最終Content-Digestを使う。つまり一つの記録だけで完結せず、「前のホップが送った」と「次のホップが受けた」を結合して再構成する。

各WITはWorkload-Identity-Tokensの一意なラベルに入り、そのメンバー自体が署名対象になる。後続は既存メンバーを保持し、自分を追加する。WITが運ばれたという事実は信頼の結論ではない。期限、鍵、信頼ドメイン、アルゴリズムを検証しなければならない。

一つのラベル、WIT、クエリ、隣接ダイジェストを失えば、集約値が無傷でも検証不能になる。Daniel Kadeが提案する最小受領書は、順序付き参加者、集約原文、検証済みWIT、署名入力、入出力ダイジェスト、再構成用経路、暗号ポリシー、検証結果を分けて保存する。これは運用上の投影であり、改訂01のデータベース指定ではない。

署名された変更は許可された変更ではない

本文はダイジェストが正しさではなく帰属を与えると明記する。悪意あるワークロードも、誤作動したモデルも、入力と出力を正確に記録して署名できる。誰が変えたかは分かるが、変える権限があったかは別の問いだ。

古い集約を捨て、自分を起点に新しい連鎖を作ることもできる。署名は新起点を識別する。起点として許されるかは認可ポリシーが決める。

そのため、参加者資格、変換履歴、集約検証、役割認可、実行と結果の五つの受領書を混ぜない。三つ目が成功しても、四つ目と五つ目は自動的に成功しない。応答も逆向きに署名されて初めて同じ保護を持つ。

一括検証は一括障害にもなる

集約は全体として検証される。一つの悪い寄与で全体が失敗し、集約だけでは故障ホップを特定できない。期限切れWIT、再構成差、拒否アルゴリズム、悪意ある参加者は連鎖全体を停止できる。

受入れは全体拒否でよくても、復旧には位置が要る。前方部分ごとの検証受領書、保護されたローカルログ、制御された再実行などを用意する必要がある。完全性の仕組みを、そのまま障害診断の仕組みと呼んではならない。

改訂01はBLSのメッセージ拡張方式を実装候補に挙げるが、WIT用識別子は別仕様に残し、BLSが耐量子ではないことも記す。WITのアルゴリズム名は事実記録であり、許可ではない。集約には全ホップで同一方式が必要で、受入れポリシーが弱い方式を排除する。

集約不能なら独立署名へ戻れる。その場合、本文を変えたホップの削除はダイジェストで分かるが、変更しなかった署名者の削除を防ぐ性質は失われる。単なる「署名済み」という一状態に潰すべきではない。

証拠は経路を漏らす

WITは参加者を、wimse-audは次の宛先を、ダイジェスト列は変換箇所を示しうる。検証包はサービス構成と処理履歴を含む機密資料でもある。保持期間、閲覧者、組織間共有を設計しなければならない。

Heng Luの現実層という見方では、ワークロードID、鍵、署名表現、変換系譜、集約検証、認可、コミット、外部効果は別記録である。動くコード優先の原則は、実際の制御面をパーサー、再構成器、WIT検証、隣接結合に置く。最小初期仕様とは、短い一フィールドではなく、第三者が検証を再現できる最小完全集合である。

出典と限界

証拠は2026年9月30日（Asia/Shanghai）に固定した。改訂01はアクティブな個人Internet-Draftであり、RFC、IETF合意、採用報告、配備済み標準ではない。変更、置換、失効の可能性がある。資料は実測負荷、相互運用、実攻撃、本番節約、適合判定、観測損失を示さない。証拠サイズ式はDaniel Kadeの説明モデルで、ベンチマークではない。