Résumé

  • Une HTTP Message Signature ne porte que sur la base de signature déclarée : une liste ordonnée de champs, de composants dérivés et de paramètres. Sa validation ne protège ni une méthode, ni une autorité, ni une cible, ni un corps qui n’y figure pas.
  • Le vérificateur doit choisir la signature pertinente, résoudre une clé admise, appliquer les règles de fraîcheur et d’unicité, recalculer le digest du contenu et relier le signataire à une permission présente. La cryptographie ne prend aucune de ces décisions à sa place.
  • Lorsqu’un proxy valide puis transforme une requête avant de la signer de nouveau, il ouvre une nouvelle étape de garde. La signature du proxy atteste sa propre vue ; elle ne réécrit pas rétroactivement ce que le client avait signé.

Le virement signé qui pouvait changer d’adresse

Une API reçoit une instruction accompagnée d’une signature correcte. L’horodatage est récent, la clé existe dans l’annuaire interne et le Content-Digest correspond au JSON reçu. À première vue, tous les voyants sont au vert.

Le détail dangereux se trouve dans Signature-Input. La liste ne couvre que date et content-digest. Elle omet @method, @authority, @target-uri, le contexte d’autorisation et toute valeur à usage unique. La preuve dit donc qu’une clé a protégé un corps donné. Elle ne dit pas que ce corps était destiné à cette opération, à cet hôte, à ce chemin ou à cette tentative précise.

Un intermédiaire peut présenter les mêmes octets à une route plus puissante. Une capture peut être rejouée tant que la fenêtre temporelle reste ouverte. Une passerelle peut remplacer l’autorité publique par un nom interne. Rien n’oblige alors la signature à échouer, car le changement se trouve hors de l’objet signé.

Il ne s’agit pas d’une faiblesse de l’algorithme. L’organisation a demandé une preuve trop étroite, puis lui a prêté un mandat qu’elle ne contenait pas.

La RFC 9421 protège un objet sémantique reconstruit

HTTP traverse des proxys, des passerelles et plusieurs versions du protocole. Les lignes de champs peuvent être combinées, l’encodage du contenu modifié et la cible réexprimée. Une signature appliquée à la suite brute d’octets casserait lors de transformations HTTP légitimes.

La RFC 9421 construit donc une base déterministe. Le signataire choisit des champs HTTP et des composants dérivés comme @method, @authority, @target-uri ou @status. Leur ordre apparaît dans Signature-Input. Une dernière ligne couvre aussi les paramètres de la signature : created, expires, keyid, nonce, tag et la liste elle-même.

Le destinataire reconstruit cette base à partir du message qu’il voit. Si la vérification réussit, il sait que le message reçu est sémantiquement équivalent au message signé pour les seuls composants couverts. Cette restriction n’est pas une note de bas de page. Elle définit exactement l’étendue de la preuve.

Deux signatures valides qui couvrent des listes différentes ne sont pas deux qualités de la même attestation. Elles portent sur deux objets différents.

Choisir la couverture, c’est choisir la politique

La norme ne peut pas imposer une liste universelle. Une application en lecture seule, une commande d’infrastructure et une instruction financière ne donnent pas la même signification aux mêmes champs. Certaines chaînes de proxys ont besoin de transformer des informations que d’autres systèmes doivent garder immuables.

Le profil du vérificateur doit donc être lié à l’opération. Il peut exiger la méthode, l’autorité, la cible, le type de contenu, le digest, un identifiant de compte et un défi d’application. Une présence générique de Signature ne satisfait pas ce contrat.

Ne rien signer d’autre que le corps permet de déplacer la commande. Signer une cible sans la méthode laisse une ambiguïté entre lecture et mutation. Laisser l’identité d’autorisation hors de la base permet d’associer une preuve intacte à un autre principal.

La réponse n’est pas de couvrir aveuglément chaque champ. Via et Forwarded sont justement destinés à évoluer au passage des intermédiaires. Les signer peut bloquer une route normale. Il faut couvrir tout élément dont la modification change la permission ou l’effet, puis documenter les transformations admises ailleurs.

Le contenu dépend d’une double vérification

La RFC 9421 n’insère pas directement un corps arbitraire dans la base. La voie ordinaire passe par la RFC 9530 : calculer Content-Digest, couvrir ce champ par la signature, vérifier la signature, puis recalculer le digest sur le contenu effectivement reçu.

Omettre la dernière étape produit une illusion fréquente. Un attaquant peut conserver la valeur signée du digest et remplacer le corps ; la signature continuera de protéger fidèlement la mauvaise référence. Inversement, un digest non signé peut être remplacé avec le contenu.

Les métadonnées comptent aussi. Content-Type et Content-Encoding peuvent changer le domaine d’interprétation ou de calcul. Un digest parfaitement égal ne garantit pas qu’un parseur donnera aux octets le même sens si la métadonnée décisive reste libre.

Un digest livré en bande-annonce arrive après le contenu et peut être supprimé par un intermédiaire. Une application qui agit au fil du flux avant de recevoir cette bande-annonce a choisi d’exécuter avant de conclure la vérification. Ce choix peut convenir à un tampon réversible, pas à une instruction irrévocable.

keyid indique où chercher, pas qui croire

Le paramètre keyid est une indication fournie par le signataire. Il ne s’authentifie pas lui-même. La norme laisse à l’application la découverte des clés, les algorithmes admis et le lien entre une clé et un rôle.

Si un service accepte toute clé qui valide sa propre signature, l’attaquant apporte sa clé, signe son message et obtient un résultat vert. La primitive prouve la possession d’un secret. Le registre local doit encore établir que cette clé appartient au bon principal, pendant le bon intervalle, pour cette classe d’opérations.

Le dossier de décision devrait donc conserver la version réelle de la clé, la source de confiance, la politique algorithmique, les dates d’activation et de retrait, le principal associé et la portée autorisée. Pendant une rotation, deux signatures peuvent être attendues. Sans calendrier explicite, la même situation peut signaler une migration, un retour d’urgence ou un élargissement clandestin.

Une entrée IANA rend un identifiant commun. Elle ne certifie pas qu’un algorithme convient à une suppression de données ou qu’un annuaire d’entreprise sait attribuer une responsabilité juridique.

La fraîcheur n’est pas l’unicité

created situe la création. expires exprime la fin de l’engagement du signataire. Le vérificateur choisit la tolérance d’horloge et la durée acceptable. Il peut donc rejeter une signature encore correcte sur le plan mathématique mais trop ancienne pour le risque traité.

Une fenêtre courte reste une fenêtre de rejeu. Tant que le système ne distingue pas une utilisation autorisée d’une seconde, le même message peut être présenté plusieurs fois.

Le paramètre nonce offre une valeur à usage unique, mais il faut la vérifier, enregistrer sa consommation de façon atomique et partager cet état entre régions. Deux centres qui lisent « inutilisé » avant d’écrire peuvent accepter ensemble la même commande. L’anti-rejeu est un système distribué, non un morceau décoratif de la base.

Le tag aide à sélectionner un profil, mais sa valeur publique peut être copiée. Il oriente le choix ; il ne donne aucune permission.

Un proxy ne devient pas le client en resignant

La RFC 9110 prévoit l’intermédiation. Une passerelle peut vérifier la signature externe, normaliser la requête, retirer une information sensible et ajouter sa propre signature interne. La RFC 9421 autorise plusieurs signatures pour représenter cette chaîne.

La nouvelle signature affirme ce que la passerelle a reçu, validé et transmis selon sa politique. Elle ne prouve pas que le client avait signé les champs ajoutés après coup. Le service final doit connaître l’autorité propre du proxy : peut-il seulement attester une vérification, ou aussi parler au nom de l’utilisateur ?

Conserver uniquement « signature passerelle valide » efface la provenance. Il faut garder la signature cliente sélectionnée, son contexte externe, le résultat de sa vérification, la transformation, puis la base interne couverte par le proxy.

La traduction entre HTTP/1.1 et HTTP/2 illustre la difficulté. L’autorité peut se trouver dans Host ou dans :authority. Le composant dérivé @authority fournit une valeur sémantique commune. Signer seulement la forme d’un protocole peut casser au changement de version ou conduire un vérificateur à utiliser le mauvais contexte.

Plusieurs signatures exigent une règle de sélection

Un même message peut porter la signature du client, celle du proxy et celle d’un approbateur. Il peut aussi présenter ancien et nouvel algorithmes pendant une migration. Chacune possède un label et une couverture propres.

Accepter la première signature valide revient à confondre pertinence et calcul. Une signature destinée à la journalisation ne vaut pas autorisation de paiement. Une attestation de passerelle ne remplace pas toujours le mandat de l’utilisateur. Le destinataire doit exiger le bon rôle, le bon label, la bonne couverture et le bon contexte.

Pour une réponse, le paramètre req permet de couvrir des composants de la requête associée. Le lecteur doit disposer exactement de cette requête. Détacher un reçu signé de sa commande puis rapprocher les deux par simple présence d’une signature détruit la relation que le mécanisme voulait protéger.

TLS, cache et autorisation restent séparés

TLS 1.3 protège un canal et fournit confidentialité et authentification selon sa configuration. La signature de message protège certains éléments au-delà d’une connexion et à travers certains intermédiaires. Elle ne chiffre rien et ne supprime pas le besoin de TLS.

L’authentification HTTP présente des justificatifs ; l’application décide encore si le principal peut agir sur cette ressource dans son état actuel. De même, une réponse signée n’est pas automatiquement réutilisable par un cache. La RFC 9111 garde cette décision.

La discipline des « reality layers » de Heng Lu aide à ne pas confondre les plans. La base est un artefact déterministe. La vérification est un résultat cryptographique. Le rattachement de clé est une déclaration d’identité. L’autorisation est une décision locale. La mutation enregistrée et ses conséquences sont la réalité opérationnelle. Aucun étage ne peut s’attribuer silencieusement les pouvoirs du suivant.

Sources et limites

Ces sources définissent des formats et des limites de sécurité. Elles ne prouvent ni le déploiement actuel, ni le comportement d’un produit nommé, ni l’identité humaine, l’intention juridique, la non-répudiation ou la justesse économique d’une commande.