要約

  • 第07版は Workload Identity Token の cnf.jwk に束縛された鍵で、メソッド、パス、クエリ、宛先、選択ヘッダー、コンテンツダイジェスト、署名メタデータを認証する。そこで得るのはリクエスト表現の証拠であり、操作権限ではない。
  • nonce の未観測は、調べたキャッシュの範囲でしか成立しない。レスポンス署名の削除を検出できるのも、クライアントが署名付き要求で明示した場合だけである。認証、再送、認可、コミット、結果は分けて記録すべきだ。

緑のランプが二つ点く

ノード A がリクエストを受ける。WIT は有効で、cnf.jwk の公開鍵が署名を検証し、Content-Digest は受信本文と一致する。wimse-aud も受信ワークロードを指し、nonce は A のローカルキャッシュにない。A は受理して nonce を保存する。

期限内に同じリクエストがノード B に届く。B は A と同じ信頼設定を持つが、nonce キャッシュは共有していない。署名は正しく、B にとって nonce は未知である。二つの緑のランプは、どちらも嘘ではない。

しかし、そのワークロードが対象資源への操作を許されているかは別問題だ。許可後にアプリケーションが状態をコミットしたかも別である。認証結果一つに三つの問いを背負わせると、暗号は正しいまま権限設計が壊れる。

draft-ietf-wimse-http-signature-07 は2026年9月20日提出で、ヘッダーは Standards Track を意図し、2027年3月24日失効とする。RFCでもなければ、特定製品の実装や普及を示す資料でもない。現行のIETFワーキンググループ Internet-Draft であり、実装状況の付録は試作の存在を示すにとどまる。

署名対象は「HTTP全体」ではない

WIMSE は RFC 9421 をプロファイルする。必須の導出コンポーネントは @method、@path、@query である。存在する場合は Content-Type、Content-Digest、Authorization、Txn-Token、Workload-Identity-Token も対象にする。本文があれば Content-Digest を含め、受信側が実際の本文から再計算する。

ダイジェスト文字列に署名があるだけでは、本文との結び付きは証明できない。RFC 9530 の意味に従って再計算し、初めて「受け取った内容」が検証対象になる。運用記録には、再構成した署名ベース、対象リスト、再計算値、判定を残す必要がある。

パラメータには created、短い expires、ランダムな nonce、タグ wimse-workload-to-workload が入り、リクエストには wimse-aud が加わる。HTTP Message Signatures の keyid と alg は使わず、WIT の cnf.jwk が鍵とアルゴリズムを示す。もっとも、受信側のローカルポリシーは、そのアルゴリズムを拒否できる。

同じ WIMSE タグを持つ署名が複数なら、選択せず拒否する。どの表現を認証したのかが曖昧なまま、送信者、プロキシ、アプリケーションが各自に都合のよい署名を指す状態を避けるためだ。

対象外のヘッダーは保護されない。プロキシが再署名すれば、新しい主体による新しい主張になる。最初の署名の範囲が後から広がるわけではない。

authority を固定しない理由

TLS終端プロキシやロードバランサーは HTTP の authority を書き換えることがある。そのため @authority は必須対象から外れ、論理的な受信者は署名パラメータ wimse-aud で束縛される。

ここで三つの概念を混ぜてはいけない。RFC 9525 に沿ったTLSサービス同一性、あるホップで見えるHTTP authority、WIMSEの宛先は、それぞれ別の判断である。TLSチャネルが正しくても宛先照合が広すぎることはある。署名が正しくても、受信サービスが宛先を拒否することもある。

証跡には、期待したサービス名、提示された同一性、TLS終端点、送信した宛先、照合結果、最終配送先を残す。一語の「authenticated」に潰すと、どの中継点が意味を変えたのか追えない。

秘密鍵を持つことと、操作を許されること

受信側は WIT を検証し、その後に束縛された鍵で署名を検証する。成功が示すのは、対応する秘密鍵の保持者が、許容時間内に対象表現を作ったという限定的な事実である。

それは要求の動機を示さず、鍵が一つの稼働インスタンスだけにあるとも証明せず、ビジネス上の役割も与えない。第07版は、認可サブシステム全体をスコープ外の信頼前提に置いている。

これは署名ゲートウェイに包括的権限を渡す指示ではない。認証は主体とリクエストを届ける。実際の効果を止められる最初のコンポーネントが、主体、操作、資源、文脈、ポリシー版を照合して認可する。

認可記録には、適用規則、許可または拒否、付帯条件、例外経路、時刻が要る。信頼ドメインの全WITを広いロールへ変換するなら、権限を生んだのはそのマッピング設定である。監査対象もそこにある。

replay の意味は配置で変わる

created と expires は使用可能な窓を狭めるが、その窓の中での二回目を止めない。nonce を覚えて初めて再送を識別できる。草案はリプレイキャッシュを許し、既知の値を拒否すべきだとする一方、複数バリデータ間の共有を要求しない。分散同期の難しさから、厳格な再送防止をプロトコル目標として保証していない。

したがってキャッシュミスは、「このノードが、この保持範囲では覚えていない」という証拠である。他ノード、別リージョン、再起動前の世代、あるいは別の要求IDで同じ業務処理が済んでいないことまでは言えない。

冪等な読み取りなら、ローカル記憶は合理的な設計になり得る。引き落とし、証明書発行、削除などでは、アプリケーション側の冪等キー、一意制約、コミット台帳が必要になる。「replay protection enabled」という表示だけでは、キャッシュ範囲、保持時間、フェイルオーバー、署名期限との関係が見えない。

レスポンス署名はクライアントの要求で成立する

サーバーは自発的にレスポンスを署名できる。しかし強い保証は、クライアントが署名済み要求内で wimse-sign-response=true を指定した場合に生じる。サーバーが署名できなければ、成功した未署名レスポンスで代用できず、クライアントも未署名なら拒否する。

署名レスポンスは必ず wimse-req-nonce を含め、要求 nonce と一致させる。これにより、単にサーバーが何かを署名したのではなく、この要求に結び付く対象レスポンスだと確認できる。

クライアントが要求していなければ、サーバー内部の署名方針だけでは削除を検出できない。中間装置が署名を落としても、クライアントは通常レスポンスを受け入れなければならない。「サーバーは署名する」は能力の説明であり、「クライアントが要求し nonce 結合を検証した」は取引の証跡である。

それでも業務完了ではない。署名レスポンスが非同期ジョブの受付を示し、その後に処理が失敗することはある。結果は別に観測する。

認可は最後の意味変換より後に置く

HTTP中継はTLSを終端し、正規化し、ルーティングし、場合によって再署名する。対象コンポーネントの変更は署名を壊すが、対象外の値は変えられる。ゲートウェイが /jobs へのPOSTを許可した後で、未署名ヘッダーにより対象テナントが決まるなら、認可は早過ぎた。

堅牢なトレースは、受信署名、変換ポリシー、再署名主体、対象差分、変換後の認可を一続きにする。HTTPの全バイトを固定する必要はない。効果を決める値を誰が変更できるかを固定する必要がある。

最終的に六つの証跡が残る。WITと鍵指紋、署名ベースと本文ダイジェスト、nonceと参照キャッシュ、主体・操作・資源・認可規則、冪等キーとコミット、そして独立した結果観測である。これらは食い違ってよい。有効な署名が再送であり、新規要求が無権限であり、許可された操作が失敗することは、すべて両立する。

実装付録や適合表は能力の主張である。稼働コードを評価するなら、実リクエスト、再構成ベース、WIT判定、キャッシュ配置、認可ログ、状態遷移を確認する。草案の改版もあり得るため、採用時には版とローカル差分を記録する。

情報源