4.3. Signatures multiples

Plusieurs signatures distinctes PEUVENT être incluses dans un seul message. Chaque signature distincte DOIT avoir une étiquette unique. Ces signatures multiples peuvent toutes être ajoutées par le même signataire, ou provenir de plusieurs signataires différents. Par exemple, un signataire peut inclure plusieurs signatures portant sur les mêmes composants du message avec des clés ou algorithmes différents pour prendre en charge des vérificateurs aux capacités variées, ou un proxy inverse peut inclure des informations sur le client dans des champs lors du transfert de la requête vers un hôte de service, y compris une signature sur les valeurs de signature d'origine du client.

L'exemple non normatif suivant commence par une requête signée du client. Un proxy inverse prend cette requête et valide la signature du client :

NOTE: pliage de ligne '' selon 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"}

Le proxy modifie ensuite le message avant de le transmettre au serveur d'origine, en changeant l'hôte cible et en ajoutant le champ d'en-tête Forwarded défini dans [RFC7239] :

NOTE: pliage de ligne '' selon RFC 8792

{"hello": "world"}

Le proxy est en mesure de valider la signature entrante du client et d'énoncer sa propre affirmation au serveur d'origine sur la nature de la requête qu'il transmet en ajoutant sa propre signature sur le nouveau message avant de la passer au serveur d'origine. Le proxy inclut également tous les éléments du message d'origine pertinents pour le traitement par le serveur d'origine. Dans de nombreux cas, le proxy voudra couvrir les mêmes composants que ceux couverts par la signature du client, ce qui est le cas dans l'exemple suivant. Notez que dans cet exemple, le proxy signe la nouvelle valeur d'autorité, qu'il a modifiée. Le proxy ajoute aussi le champ d'en-tête Forwarded à sa propre valeur de signature. Le proxy identifie sa propre clé et son algorithme et, dans cet exemple, inclut une expiration pour la signature afin d'indiquer aux systèmes en aval que le proxy ne cautionnera pas ce message signé au-delà de cette courte fenêtre temporelle. Il en résulte une base de signature de :

NOTE: pliage de ligne '' selon 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

et une valeur de sortie de signature de :

NOTE: pliage de ligne '' selon RFC 8792

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

Ces valeurs sont ajoutées au message de requête HTTP par le proxy. La signature d'origine est incluse sous l'étiquette sig1, et la signature du proxy inverse sous l'étiquette proxy_sig. Le proxy utilise la clé test-key-rsa pour créer sa signature avec l'algorithme de signature rsa-v1_5-sha256, tandis que la signature d'origine du client a été produite avec la clé test-key-rsa-pss et un algorithme de signature RSA-PSS :

NOTE: pliage de ligne '' selon 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"}

Bien que le proxy puisse en outre inclure la valeur du champ Signature du client et les champs Signature-Input du message d'origine dans les composants couverts de la nouvelle signature, cette pratique N'EST PAS RECOMMANDÉE en raison de faiblesses connues liées à la signature de valeurs de signature, comme discuté à la Section 7.3.7. Le proxy est en mesure de valider la signature du client ; les modifications que le proxy apporte au message invalideront la signature existante lorsque le message est vu par le serveur d'origine. Dans cet exemple, le serveur d'origine peut disposer d'informations supplémentaires dans son contexte de signature pour tenir compte du changement d'autorité, bien que cette pratique exige une configuration supplémentaire et une grande prudence comme discuté à la Section 7.4.4. Dans d'autres applications, le serveur d'origine ne pourra pas vérifier la signature d'origine lui-même mais voudra tout de même vérifier que le proxy a effectué la validation appropriée de la signature du client. Une application qui doit signaler un traitement ou une réception réussie d'une signature devrait spécifier avec soin des mécanismes alternatifs pour envoyer un tel signal de façon sécurisée.

4.3. Signatures multiples​

4.3. Signatures multiples