メインコンテンツまでスキップ

4.3. 複数の署名 (Multiple Signatures)

4.3. 複数の署名 (Multiple Signatures)

1 つのメッセージに, 複数の異なる署名を含めてもよい (MAY). 各異なる署名は一意のラベルを持たなければならない (MUST). これらの複数の署名はすべて同一署名者が付与したものでもよく, 複数の異なる署名者によるものでもよい. 例えば, 署名者は能力の異なる検証者を支援するため, 同一のメッセージコンポーネントに対して異なる鍵またはアルゴリズムで複数の署名を付与してもよい. または, リバースプロキシがリクエストをサービスホストに転送する際にクライアントに関する情報をフィールドに含め, クライアントの元の署名値に対する署名を含めてもよい.

以下の非規範的な例は, クライアントからの署名付きリクエストから始まる. リバースプロキシがそのリクエストを受け取り, クライアントの署名を検証する:

NOTE: RFC 8792 に従う '' による行折り返し

POST /foo?param=Value&Pet=dog HTTP/1.1 Host: example.com Date: Tue, 20 Apr 2021 02:07:55 GMT Content-Type: application/json Content-Length: 18 Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: Signature-Input: sig1=("@method" "@authority" "@path"
"content-digest" "content-type" "content-length")
;created=1618884475;keyid="test-key-ecc-p256" Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp
+kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:

{"hello": "world"}

プロキシはオリジンサーバに転送する前にメッセージを変更し, ターゲットホストを変え, [RFC7239] で定義される Forwarded ヘッダフィールドを追加する:

NOTE: RFC 8792 に従う '' による行折り返し

POST /foo?param=Value&Pet=dog HTTP/1.1 Host: origin.host.internal.example Date: Tue, 20 Apr 2021 02:07:56 GMT Content-Type: application/json Content-Length: 18 Forwarded: for=192.0.2.123;host=example.com;proto=https Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: Signature-Input: sig1=("@method" "@authority" "@path"
"content-digest" "content-type" "content-length")
;created=1618884475;keyid="test-key-ecc-p256" Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp
+kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:

{"hello": "world"}

プロキシは着信クライアント署名を検証し, オリジンサーバに転送しているリクエストの性質について独自の表明を行う立場にあり, オリジンに渡す前に新しいメッセージに対する自身の署名を付与することでそれを行う. プロキシはまた, オリジンサーバの処理に関連する元メッセージの要素をすべて含める. 多くの場合, プロキシはクライアントの署名が被覆したのと同じコンポーネントをすべて被覆したいと考え, 以下の例がその場合である. 本例では, プロキシは変更した新しい authority 値を被覆して署名している. プロキシはまた Forwarded ヘッダフィールドを自身の署名値に追加する. プロキシは自身の鍵とアルゴリズムを識別し, 本例では下流システムに対し, この短い時間窓を過ぎてもプロキシがこの署名付きメッセージを保証しないことを示すため, 署名の有効期限を含める. これにより次の署名ベースとなる:

NOTE: RFC 8792 に従う '' による行折り返し

"@method": POST "@authority": origin.host.internal.example "@path": /foo "content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX
+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: "content-type": application/json "content-length": 18 "forwarded": for=192.0.2.123;host=example.com;proto=https "@signature-params": ("@method" "@authority" "@path"
"content-digest" "content-type" "content-length" "forwarded")
;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"
;expires=1618884540

および次の署名出力値となる:

NOTE: RFC 8792 に従う '' による行折り返し

S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+JH+8XY1I6+8Cy
+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49GwiyUpZ10KHgOEe11s
x3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7LB5YAv0RAGhB8tmpv7sFn
Im9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtflzvZdXAsD3LH2TwevU+/PBPv0
B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbLVdp770I6VHR6WfgS9ddzirrswsE1w
5o0LV/g==

これらの値はプロキシによって HTTP リクエストメッセージに追加される. 元の署名はラベル sig1 の下に含まれ, リバースプロキシの署名はラベル proxy_sig の下に含まれる. プロキシは rsa-v1_5-sha256 署名アルゴリズムで test-key-rsa 鍵を用いて署名を作成し, 一方クライアントの元の署名は test-key-rsa-pss 鍵および RSA-PSS 署名アルゴリズムで作成された:

NOTE: RFC 8792 に従う '' による行折り返し

POST /foo?param=Value&Pet=dog HTTP/1.1 Host: origin.host.internal.example Date: Tue, 20 Apr 2021 02:07:56 GMT Content-Type: application/json Content-Length: 18 Forwarded: for=192.0.2.123;host=example.com;proto=https Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T
aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: Signature-Input: sig1=("@method" "@authority" "@path"
"content-digest" "content-type" "content-length")
;created=1618884475;keyid="test-key-ecc-p256",
proxy_sig=("@method" "@authority" "@path" "content-digest"
"content-type" "content-length" "forwarded")
;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"
;expires=1618884540 Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp
+kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:,
proxy_sig=:S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+
JH+8XY1I6+8Cy+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49G
wiyUpZ10KHgOEe11sx3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7
LB5YAv0RAGhB8tmpv7sFnIm9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtf
lzvZdXAsD3LH2TwevU+/PBPv0B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbL
Vdp770I6VHR6WfgS9ddzirrswsE1w5o0LV/g==:

{"hello": "world"}

プロキシは元メッセージのクライアントの Signature フィールド値および Signature-Input フィールドを新しい署名の被覆コンポーネントに追加してもよいが, 7.3.7 節で論じるとおり署名値への署名には既知の弱点があるため, その慣行は推奨されない (NOT RECOMMENDED). プロキシはクライアントの署名を検証する立場にあり, プロキシがメッセージに加える変更はオリジンサーバがメッセージを見たときに既存の署名を無効にする. 本例では, オリジンサーバが authority の変更を考慮するための署名コンテキストに追加情報を持つことは可能だが, その慣行には 7.4.4 節で論じる追加設定と特別な注意が必要である. その他のアプリケーションでは, オリジンサーバは元の署名自体を検証できないが, プロキシがクライアントの署名について適切な検証を行ったことを検証したい場合もある. 署名の処理または受領の成功を通知する必要があるアプリケーションは, そのような信号を安全に送る代替手段を慎重に規定する必要がある.