1.2. Exigences (Requirements)

1.2. Exigences

HTTP autorise, et parfois exige, que des intermédiaires transforment les messages de diverses façons. Le destinataire peut alors recevoir un message qui n'est pas équivalent bit à bit au message envoyé à l'origine. Dans ce cas, il ne peut pas vérifier des protections d'intégrité sur les octets bruts du message HTTP de l'émetteur, car la vérification des signatures numériques ou des MAC exige que le signataire et le vérificateur disposent exactement de la même base de signature. Les octets bruts exacts du message ne pouvant pas servir de source fiable pour une base de signature, le signataire et le vérificateur doivent créer indépendamment la base de signature à partir de leur version respective du message, via un mécanisme résilient aux changements sûrs qui n'altèrent pas la signification du message.

Pour diverses raisons, il est peu pratique de définir strictement ce qui constitue un changement sûr par rapport à un changement dangereux. Les applications emploient HTTP de bien des manières et peuvent diverger sur la pertinence d'une information donnée dans un message (par exemple le contenu du message, la méthode ou un champ d'en-tête particulier). Une solution généraliste doit donc laisser au signataire un certain contrôle sur les composants de message signés.

Les applications HTTP peuvent s'exécuter dans des environnements qui ne donnent pas un accès ou un contrôle complets sur les messages HTTP (comme l'environnement JavaScript d'un navigateur) ou utiliser des bibliothèques qui masquent les détails du protocole (comme la bibliothèque client HTTP Java (https://openjdk.java.net/groups/net/httpclient/intro.html)). Ces applications doivent pouvoir générer et vérifier des signatures malgré une connaissance incomplète du message HTTP.