2.4. Signer des composants de requête dans un message de réponse (Signing Request Components in a Response Message)
2.4. Signer des composants de requête dans un message de réponse
Lorsqu'un message de requête aboutit à un message de réponse signé, le signataire peut inclure des parties du message de requête dans la base de signature en ajoutant le paramètre req à l'identifiant de composant.
req Un indicateur Boolean indiquant que la valeur de composant est dérivée de la requête ayant déclenché ce message de réponse et non directement du message de réponse.
Ce paramètre peut s'appliquer aux champs HTTP et aux composants dérivés ciblant la requête, avec la même sémantique. La valeur de composant pour un composant de message utilisant ce paramètre est calculée comme d'habitude, mais les données sont tirées du message de requête au lieu du message de réponse cible auquel la signature s'applique.
Notez que le même nom de composant PEUT être inclus avec et sans le paramètre req dans une seule base de signature, désignant le même composant nommé à la fois dans le message de requête et dans le message de réponse.
Le paramètre req PEUT être combiné avec d'autres paramètres selon l'identifiant de composant, comme le paramètre key pour un champ Dictionary.
Par exemple, lors de la réponse à cette requête:
NOTE: retour à la ligne '' selon la 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"}
On obtient le message de réponse non signé suivant:
NOTE: retour à la ligne '' selon la 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"}
Le serveur signe la réponse avec sa propre clé, en incluant le code @status et plusieurs champs d'en-tête parmi les composants couverts. Bien que cela couvre une part raisonnable de la réponse pour cette application, le serveur inclut en outre plusieurs composants dérivés du message de requête d'origine ayant déclenché cette réponse. Dans cet exemple, le serveur inclut la méthode, l'autorité, le chemin et le condensat de contenu (content digest) de la requête parmi les composants couverts de la réponse. Le Content-Digest de la requête et de la réponse est inclus sous la signature de la réponse. Pour l'application de cet exemple, la requête (query) n'est pas jugée pertinente pour la réponse et n'est donc pas couverte. D'autres applications trancheraient différemment selon les besoins, comme à la Section 1.4.
La base de signature pour cet exemple est:
NOTE: retour à la ligne '' selon la 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"
Le message de réponse signé est:
NOTE: retour à la ligne '' selon la 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"}
Notez que l'algorithme de signature ECDSA utilisé ici est non déterministe: une valeur de signature différente est produite à chaque exécution. La valeur de signature fournie ici peut être validée avec les clés données, mais les valeurs nouvellement générées ne sont pas censées correspondre à l'exemple. Voir Section 7.3.5.
Comme les valeurs de composant de la requête ne sont pas répétées dans le message de réponse, le demandeur DOIT conserver les valeurs de composant du message d'origine assez longtemps pour valider la signature de la réponse qui utilise ce paramètre d'identifiant de composant. Dans la plupart des cas, cela signifie que le demandeur doit conserver le message de requête d'origine, car le signataire peut choisir d'inclure toute partie de la requête dans sa réponse, selon les besoins de l'application. Comme un intermédiaire peut altérer un message de requête avant traitement par le serveur, les applications doivent veiller à ne pas signer de telles valeurs altérées, car le client ne pourrait pas valider la signature résultante.
Il est aussi possible qu'un serveur crée une réponse signée en réponse à une requête signée. Pour cet exemple de requête signée:
NOTE: retour à la ligne '' selon la 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"}
Le serveur pourrait choisir de signer des parties de cette réponse, y compris plusieurs parties de la requête, produisant cette base de signature:
NOTE: retour à la ligne '' selon la 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"
et la réponse signée suivante:
NOTE: retour à la ligne '' selon la 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"}
Notez que l'algorithme de signature ECDSA utilisé ici est non déterministe, comme expliqué ci-dessus. Voir Section 7.3.5.
Les applications qui signent une réponse à une requête signée DEVRAIENT signer tous les composants de la valeur de signature de la requête pour fournir une couverture suffisante et se prémunir contre une classe d'attaques par collision, comme à la Section 7.3.7. Le serveur de cet exemple a inclus tous les composants énumérés dans le champ Signature-Input de la signature client sur la requête dans la signature de la réponse, en plus des composants de la réponse.
Bien qu'il soit syntaxiquement possible d'inclure les champs Signature et Signature-Input du message de requête dans les composants de signature d'une réponse, cette pratique est NON RECOMMANDÉE. En effet, les signatures de signatures ne fournissent pas la couverture transitive des composants couverts qu'on pourrait attendre, et la pratique est vulnérable à plusieurs attaques comme à la Section 7.3.7. Une application devant signaler un traitement ou une réception réussie de signature devrait spécifier soigneusement des mécanismes de signalisation alternatifs sûrs.
La signature de réponse ne peut couvrir, avec cet indicateur, que ce qui figure dans le message de requête. Par conséquent, si une application doit inclure le contenu du message de requête sous la signature de sa réponse, le client doit prévoir un moyen de couvrir ce contenu, tel qu'un champ Content-Digest. Voir la discussion à la Section 7.2.8.
Le paramètre req NE DOIT PAS être utilisé pour un composant d'une signature qui cible un message de requête.