2.4. レスポンスメッセージにおけるリクエストコンポーネントの署名

2.4. レスポンスメッセージにおけるリクエストコンポーネントの署名

リクエストメッセージの結果として署名付きレスポンスメッセージが返る場合, 署名者はコンポーネント識別子に req パラメータを付加することで, リクエストメッセージの一部を署名ベースに含めてよい.

req コンポーネント値がこのレスポンスメッセージを直接ではなく, このレスポンスを引き起こしたリクエストから導出されることを示すブールフラグ.

このパラメータは, リクエストを対象とする HTTP フィールドおよび派生コンポーネントの両方に適用でき, 意味は同じである. このパラメータを用いるメッセージコンポーネントのコンポーネント値は, 通常と同じ方法で算出されるが, データは署名が適用される対象レスポンスメッセージではなくリクエストメッセージから取り出される.

同一のコンポーネント名を, req パラメータありとなしの両方で単一の署名ベースに含めてもよい (MAY). それはリクエストメッセージとレスポンスメッセージの双方から同一の名前のコンポーネントを示す.

req パラメータは, Dictionary フィールドの key パラメータなど, コンポーネント識別子に適切な他のパラメータと組み合わせてもよい (MAY).

例えば, 次のリクエストに対するレスポンスを返す場合:

NOTE: '' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1 Host: example.com Date: Tue, 20 Apr 2021 02:07:55 GMT Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: Content-Type: application/json Content-Length: 18

{"hello": "world"}

次の未署名レスポンスメッセージとなる:

NOTE: '' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable Date: Tue, 20 Apr 2021 02:07:56 GMT Content-Type: application/json Content-Length: 62 Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn
HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:

{"busy": true, "message": "Your call is very important to us"}

サーバーは自鍵でレスポンスに署名し, 被覆コンポーネントに @status コードと複数のヘッダフィールドを含める. このアプリケーションにとってレスポンスの相当部分を被覆する一方で, サーバーはこのレスポンスを引き起こした元のリクエストメッセージから導出される複数のコンポーネントを追加で含める. この例では, サーバーはメソッド, オーソリティ, パス, およびリクエストのコンテンツダイジェストをレスポンスの被覆コンポーネントに含める. リクエストとレスポンスの両方の Content-Digest がレスポンス署名の下に含まれる. この例のアプリケーションでは, クエリはレスポンスに関連しないと判断され被覆されない. 他のアプリケーションは 1.4 節で述べるとおりアプリケーションの必要性に基づき異なる判断をする.

この例の署名ベースは次のとおり:

NOTE: '' line wrapping per RFC 8792

"@status": 503 "content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf
wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==: "content-type": application/json "@authority";req: example.com "@method";req: POST "@path";req: /foo "content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A
2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: "@signature-params": ("@status" "content-digest" "content-type"
"@authority";req "@method";req "@path";req "content-digest";req)
;created=1618884479;keyid="test-key-ecc-p256"

署名付きレスポンスメッセージは次のとおり:

NOTE: '' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable Date: Tue, 20 Apr 2021 02:07:56 GMT Content-Type: application/json Content-Length: 62 Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn
HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==: Signature-Input: reqres=("@status" "content-digest" "content-type"
"@authority";req "@method";req "@path";req "content-digest";req)
;created=1618884479;keyid="test-key-ecc-p256" Signature: reqres=:dMT/A/76ehrdBTD/2Xx8QuKV6FoyzEP/I9hdzKN8LQJLNgzU
4W767HK05rx1i8meNQQgQPgQp8wq2ive3tV5Ag==:

{"busy": true, "message": "Your call is very important to us"}

ここで用いている ECDSA 署名アルゴリズムは非決定的であるため, アルゴリズムを実行するたびに異なる署名値が生成される. ここに示した署名値は与えられた鍵に対して検証できるが, 新たに生成した署名値が例と一致することは期待されない. 7.3.5 節を参照のこと.

リクエストからのコンポーネント値はレスポンスメッセージに繰り返されないため, リクエスト送信者はこのコンポーネント識別子パラメータを用いるレスポンスの署名を検証するのに十分な期間, 元のメッセージコンポーネント値を保持しなければならない (MUST). 多くの場合, 署名者はアプリケーションの必要性に応じレスポンスにリクエストの任意の部分を含め得るため, リクエスト送信者は元のリクエストメッセージを保持する必要がある. 中間者がサーバーが処理する前にリクエストメッセージを改変し得るため, アプリケーションはそのような改変された値に署名しないよう注意しなければならない. クライアントは結果の署名を検証できないからである.

サーバーは署名付きリクエストに対して署名付きレスポンスを作成することもできる. 次の署名付きリクエストの例について:

NOTE: '' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1 Host: example.com Date: Tue, 20 Apr 2021 02:07:55 GMT Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: Content-Type: application/json Content-Length: 18 Signature-Input: sig1=("@method" "@authority" "@path" "@query"
"content-digest" "content-type" "content-length")
;created=1618884475;keyid="test-key-rsa-pss" Signature: sig1=:e8UJ5wMiRaonlth5ERtE8GIiEH7Akcr493nQ07VPNo6y3qvjdK
t0fo8VHO8xXDjmtYoatGYBGJVlMfIp06eVMEyNW2I4vN7XDAz7m5v1108vGzaDljr
d0H8+SJ28g7bzn6h2xeL/8q+qUwahWA/JmC8aOC9iVnwbOKCc0WSrLgWQwTY6VLp4
2Qt7jjhYT5W7/wCvfK9A1VmHH1lJXsV873Z6hpxesd50PSmO+xaNeYvDLvVdZlhtw
5PCtUYzKjHqwmaQ6DEuM8udRjYsoNqp2xZKcuCO1nKc0V3RjpqMZLuuyVbHDAbCzr
0pg2d2VM/OC33JAU7meEjjaNz+d7LWPg==:

{"hello": "world"}

サーバーはこのレスポンスの一部に署名する際, リクエストの複数部分を含めて次の署名ベースとすることができる:

NOTE: '' line wrapping per RFC 8792

"@status": 503 "content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf
wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==: "content-type": application/json "@authority";req: example.com "@method";req: POST "@path";req: /foo "@query";req: ?param=Value&Pet=dog "content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A
2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: "content-type";req: application/json "content-length";req: 18 "@signature-params": ("@status" "content-digest" "content-type"
"@authority";req "@method";req "@path";req "@query";req
"content-digest";req "content-type";req "content-length";req)
;created=1618884479;keyid="test-key-ecc-p256"

および次の署名付きレスポンスとなる:

NOTE: '' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable Date: Tue, 20 Apr 2021 02:07:56 GMT Content-Type: application/json Content-Length: 62 Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn
HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==: Signature-Input: reqres=("@status" "content-digest" "content-type"
"@authority";req "@method";req "@path";req "@query";req
"content-digest";req "content-type";req "content-length";req)
;created=1618884479;keyid="test-key-ecc-p256" Signature: reqres=:C73J41GVKc+TYXbSobvZf0CmNcptRiWN+NY1Or0A36ISg6ym
dRN6ZgR2QfrtopFNzqAyv+CeWrMsNbcV2Ojsgg==:

{"busy": true, "message": "Your call is very important to us"}

ここで用いている ECDSA 署名アルゴリズムは非決定的であるため, アルゴリズムを実行するたびに異なる署名値が生成される. ここに示した署名値は与えられた鍵に対して検証できるが, 新たに生成した署名値が例と一致することは期待されない. 7.3.5 節を参照のこと.

署名付きリクエストへのレスポンスに署名するアプリケーションは, 7.3.7 節で述べる衝突攻撃のクラスに対する十分な被覆と保護を与えるため, リクエスト署名値のすべてのコンポーネントに署名すべきである (SHOULD). この例のサーバーは, レスポンスのコンポーネントに加え, クライアントのリクエスト上の署名の Signature-Input フィールドに列挙されたすべてのコンポーネントをレスポンス署名に含めている.

この仕組みを用いるメッセージへのレスポンスの署名コンポーネントにリクエストメッセージの Signature および Signature-Input フィールドを含めることは構文的には可能だが, この慣行は推奨されない (NOT RECOMMENDED). 署名の署名は, 期待され得るような被覆コンポーネントの推移的被覆を提供せず, 7.3.7 節で述べる複数の攻撃に対して脆弱だからである. 署名の処理または受領の成功を通知する必要があるアプリケーションは, そのような信号を安全に送る代替手段を慎重に規定する必要がある.

このフラグを用いる場合, レスポンス署名が被覆し得るのはリクエストメッセージに含まれるものに限られる. したがって, アプリケーションがレスポンスの署名の下にリクエストのメッセージ本文を含める必要がある場合, クライアントはその本文を被覆する手段 (Content-Digest フィールドなど) を含める必要がある. 詳細は 7.2.8 節の議論を参照のこと.

req パラメータは, リクエストメッセージを対象とする署名のいかなるコンポーネントにも使用してはならない (MUST NOT).