1.4. Application des signatures de message HTTP (Application of HTTP Message Signatures)

1.4. Application des signatures de message HTTP

Les signatures de message HTTP sont conçues comme un outil généraliste utilisable dans de nombreux contextes et applications. Pour appliquer correctement et en toute sécurité les signatures de message HTTP, une application ou un profil de cette spécification DOIT préciser, au minimum, tous les éléments suivants:

• L'ensemble des identifiants de composants (Section 2) et des paramètres de signature (Section 2.3) attendus et requis dans la liste des composants couverts. Par exemple, un protocole d'autorisation pourrait imposer que le champ Authorization soit couvert pour protéger les informations d'autorisation et imposer que les paramètres de signature contiennent un paramètre created (Section 2.3), tandis qu'une API dont le contenu HTTP est sémantiquement pertinent pourrait exiger la présence et la couverture du champ Content-Digest défini dans [DIGEST] ainsi qu'une valeur du paramètre tag (Section 2.3) propre à l'API protégée.

• Les types Structured Field [STRUCTURED-FIELDS] attendus pour tout champ ou paramètre de composant couvert requis ou attendu.

• Un moyen d'obtenir le matériel de clé utilisé pour vérifier la signature. Une application utilisera en général le paramètre keyid des paramètres de signature (Section 2.3) et définira des règles pour résoudre une clé à partir de celui-ci, bien que la clé appropriée puisse être connue par d'autres moyens, comme la préinscription de la clé du signataire.

• L'ensemble des algorithmes de signature autorisés pour les signataires et acceptés par les vérificateurs.

• Un moyen de déterminer que l'algorithme de signature utilisé pour vérifier la signature convient au matériel de clé et au contexte du message. Par exemple, le processus peut employer le paramètre alg des paramètres de signature (Section 2.3) pour indiquer explicitement l'algorithme, le déduire du matériel de clé, ou utiliser un algorithme préconfiguré convenu entre signataire et vérificateur.

• Un moyen de déterminer qu'une clé et un algorithme donnés pour une signature conviennent au contexte du message. Par exemple, un serveur n'attendant que des signatures ECDSA doit savoir rejeter toute signature RSA, ou un serveur n'attendant que de la cryptographie asymétrique doit savoir rejeter toute cryptographie symétrique.

• Un moyen de déterminer le contexte pour la dérivation des composants de message à partir d'un message HTTP et de son contexte applicatif. En principe il s'agit du message HTTP cible lui-même, mais le contexte peut inclure des informations supplémentaires connues de l'application par configuration, comme un nom d'hôte externe.

• Si une liaison entre requête et réponse est nécessaire via le mécanisme de la Section 2.4, tous les éléments des messages requête et réponse qui seraient requis pour fournir les propriétés d'une telle liaison.

• Les messages d'erreur et codes renvoyés par le vérificateur au signataire lorsque la signature est invalide, le matériel de clé inadéquat, la fenêtre de validité hors spécification, une valeur de composant ne peut pas être calculée, ou toute autre erreur survient pendant la vérification. Par exemple, si la signature sert de mécanisme d'authentification, un code d'état HTTP 401 (Unauthorized) ou 403 (Forbidden) peut convenir. Si la réponse provient d'une API HTTP, une réponse avec un code tel que 400 (Bad Request) peut inclure plus de détails [RFC7807] [RFC9457], par exemple une indication que le mauvais matériel de clé a été utilisé.

Lors du choix de ces paramètres, une application des signatures de message HTTP doit garantir que le vérificateur aura accès à toutes les informations requises pour recréer la base de signature. Par exemple, un serveur derrière un mandataire inverse devrait connaître l'URI de requête d'origine pour utiliser le composant dérivé @target-uri, bien que l'URI cible apparente soit modifiée par le mandataire (voir aussi Section 7.4.3). De plus, une application utilisant des signatures dans les réponses doit s'assurer que les clients recevant des réponses signées ont accès à toutes les parties signées du message, y compris les parties de la requête que le serveur a signées au moyen du paramètre req (« request-response ») (Section 2.4).

Les détails de ce type de profilage relèvent de l'application et sortent du périmètre de cette spécification; des considérations supplémentaires sont toutefois abordées à la Section 7. En particulier, lors du choix de l'ensemble requis d'identifiants de composants, il faut veiller à une couverture suffisante pour l'application, comme aux Sections 7.2.1 et 7.2.8. Cette spécification ne définit qu'une partie d'un système de sécurité complet pour une application. Lors de la construction d'un tel système fondé sur cet outil, il importe d'analyser la sécurité de l'ensemble du système, dont les signatures de message HTTP font partie. Des systèmes historiques, tels qu'AWS Signature Version 4 [AWS-SIGv4], peuvent inspirer et illustrer l'application de mécanismes analogues, mais leur examen ne dispense pas d'analyser la sécurité d'une application des signatures de message HTTP.