7.4.4. 複数のメッセージコンポーネントコンテキスト (Multiple Message Component Contexts)

7.4.4. 複数のメッセージコンポーネントコンテキスト (Multiple Message Component Contexts)

単一のメッセージ内に存在する各署名について, メッセージコンポーネントの値を導出するコンテキストが異なりうる. これは特に, プロキシがメッセージを変異させ, 既存の署名に加えて変異後の値への署名を含めるときに当てはまる. 例えば, リバースプロキシは, リクエスト内の公開ホスト名を, 転送先の個別のサービスホストのホスト名に置き換えうる. クライアントとリバースプロキシの双方が @authority をカバーする署名を追加する場合, サービスホストはリクエスト上に 2 つの署名を見る. それぞれが @authority メッセージコンポーネントの異なる値に署名し, メッセージがクライアントからサービスホストへ至る過程での当該コンポーネントの変更を反映する.

そのような場合, 内部サービスは署名の 1 つだけを検証するか, 7.4.3 節で論じるとおり外部設定情報を用いることが一般的である. しかし, 両方の署名を処理する検証者は, @authority コンポーネントのコンポーネント値が署名ごとに異なるため, 署名ごとに異なるメッセージコンポーネントコンテキストを用いなければならない. このような検証者は, 着信メッセージに対するリバースプロキシのコンテキストと, リバースプロキシから来るメッセージに対する対象サービスのコンテキストの双方を把握する必要がある. 検証者は, 正しいコンテキストを正しい署名に適用することに特に注意する必要がある. さもなければ, 攻撃者はこの複雑な構成の知識を悪用して検証者への入力を混同させうる.

そのような検証者はまた, 署名間のメッセージコンポーネントコンテキストの差異が想定内で許容されることを確保する必要がある. 例えば, 上記のシナリオでは, リバースプロキシは元のホスト名を Forwarded ヘッダフィールドに含め, @authority, forwarded, および Signature フィールド内のクライアントのエントリに署名しうる. 検証者は Forwarded ヘッダフィールドのホスト名を用いて, ホスト名が想定どおり変換されたことを確認できる.