Résumé

  • Want-Content-Digest et Want-Repr-Digest ordonnent des préférences d’algorithmes. Ils ne constituent pas une négociation contraignante : le destinataire peut les ignorer, retenir un autre algorithme ou ne renvoyer aucun champ de condensat.
  • Une trace d’intégrité sérieuse sépare quatre faits : le souhait envoyé, le champ réellement reçu, l’objet HTTP effectivement couvert et le résultat du calcul assorti de la décision locale.
  • Un condensat ne donne ni identité, ni autorisation, ni confidentialité, ni protection automatique de toutes les métadonnées. Son rôle est plus étroit : comparer des octets précisément délimités.

La commande n’est pas passée au moment de la préférence

Le mot Want peut tromper. Dans un contrat commercial, « nous voulons SHA-512 » peut être lu comme une exigence. Dans le protocole, le même énoncé reste une indication de préférence tant que l’application n’a pas ajouté sa propre condition.

RFC9530 définit deux dictionnaires fondés sur les Structured Fields. Want-Content-Digest porte sur le contenu du message ; Want-Repr-Digest porte sur la représentation sélectionnée. Chaque clé désigne un algorithme et chaque entier indique sa place relative : 1 est la préférence la plus faible, 10 la plus forte, 0 signifie que l’algorithme n’est pas acceptable.

Cette échelle ne mesure ni la robustesse cryptographique, ni le degré de confiance. Elle ne transforme pas davantage le choix classé en obligation. Le pair peut ne pas tenir compte du dictionnaire, produire un algorithme qui n’y figure pas, ou ne produire ni Content-Digest ni Repr-Digest. La spécification précise que le seul écart à la préférence ne constitue pas une erreur de protocole.

Une application peut parfaitement décider le contraire pour son service : absence interdite, liste fermée d’algorithmes, ou réponse d’erreur déterminée. Elle doit alors publier et tester cette règle. L’annexe C de RFC9530 illustre plusieurs issues possibles — algorithme moins bien classé, choix tous incompatibles, 4xx ou 5xx décidé par l’application — sans imposer un code universel.

La direction du message ajoute un piège. Lorsqu’un serveur place un champ Want-* dans sa réponse, il exprime ce qu’il souhaite recevoir dans des requêtes ultérieures. Ce champ ne prouve rien sur le corps de la réponse présente. Il faut donc résister à un raccourci fréquent dans les passerelles : la présence du mot « Digest » n’implique pas qu’un condensat ait été fourni.

Une chaîne d’intégrité comporte quatre reçus

Pour comprendre une transaction, il faut pouvoir relire quatre reçus distincts.

Le premier conserve la préférence : nom du champ, membres proposés, poids relatifs. Le deuxième décrit le message observé : champ de preuve présent ou absent, algorithmes offerts, emplacement dans les en-têtes ou dans les trailers. Le troisième fixe le périmètre : contenu de ce message ou représentation sélectionnée. Le quatrième consigne l’acte local : membre accepté, octets calculés, correspondance ou écart, décision prise par l’application.

Ces reçus empêchent des équivalences abusives. Une préférence pour SHA-512 ne prouve pas que SHA-512 a été renvoyé. La présence de sha-256 ne prouve pas que le destinataire l’a calculé. Un calcul concordant ne dit rien si l’on ignore s’il portait sur le contenu ou sur la représentation.

Ils rendent aussi visibles les accommodements légitimes. Accepter un algorithme moins bien classé peut être conforme à la politique. Continuer sans condensat peut convenir à une ressource publique à faible risque. Mais le journal doit dire « absence acceptée » ou « solution de repli acceptée », plutôt que d’enregistrer un succès générique. Sinon, la compatibilité d’aujourd’hui devient la garantie imaginaire de demain.

Le contenu n’est pas la représentation

RFC3230 parlait d’instance digest dans un vocabulaire qui laissait persister des ambiguïtés. RFC9530 nomme désormais deux objets. Content-Digest couvre le contenu réel d’un message HTTP. Repr-Digest couvre la représentation sélectionnée dans son ensemble, conformément à la sémantique HTTP.

La différence apparaît clairement avec un transfert partiel, mais elle dépasse le cas des plages. Une ressource peut avoir plusieurs représentations. Content-Type et Content-Encoding participent à leur définition ; un même objet perçu par l’utilisateur peut donc correspondre à des suites d’octets différentes. Le fichier accessible sur un disque n’est pas automatiquement le bon objet à condenser.

Les méthodes qui modifient l’état imposent la même discipline. Dans une requête PATCH, la représentation portée peut être le document de modification ; dans la réponse, la représentation sélectionnée peut être celle de la ressource après traitement. Content-Location et Location ne sont pas des synonymes permettant de réattribuer librement un résultat.

Une plateforme qui ne conserve qu’une colonne « checksum du payload » supprime précisément l’information nécessaire. Elle devrait indiquer le champ utilisé, les métadonnées de représentation, le traitement de l’encodage et l’étape à laquelle les octets ont été capturés. Deux équipes peuvent sinon obtenir deux valeurs correctes sur deux objets différents et croire qu’elles partagent la même preuve.

L’agilité ne dispense pas d’une politique d’acceptation

Le registre IANA actuel marque SHA-512 et SHA-256 comme actifs. MD5, SHA, les sommes UNIX, Adler-32 et CRC32C figurent parmi les valeurs dépréciées. RFC9530 tolère encore des algorithmes dépréciés dans certains usages non adversariaux de détection d’altération accidentelle, mais les exclut lorsqu’un adversaire ou une signature numérique entre en jeu.

Cette classification commune ne répond pas à toutes les questions d’une application. Un destinataire peut ignorer certains membres, voire tous. Il peut limiter les algorithmes calculés, le nombre de membres et la taille du contenu traité. Le calcul de multiples condensats sur un flux important a un coût ; laisser le pair élargir sans borne ce travail créerait une surface de consommation évitable.

Il faut surtout séparer « compris par la bibliothèque » de « accepté par la politique ». Si un message offre à la fois un membre actif et un membre déprécié, un composant ne devrait pas valider le plus facile pendant qu’un autre suppose que la préférence la plus forte a été respectée. L’agilité ne bloque pas automatiquement une substitution ou un repli vers le maillon le plus faible.

Le journal pertinent cite donc l’algorithme réellement retenu, le champ, l’objet et le résultat. L’application décide si une seule concordance acceptable suffit, comment traiter des membres contradictoires et ce qu’elle fait lorsqu’elle ne reconnaît que des valeurs interdites. La syntaxe commune rend ce choix interopérable ; elle ne l’effectue pas à la place du responsable du risque.

Un trailer tardif ne valide pas une décision déjà prise

Les champs de condensat peuvent se trouver dans les en-têtes ou dans les trailers. Le trailer permet à un émetteur de calculer pendant la diffusion, mais sa chronologie compte. Un intermédiaire peut le supprimer. Une application peut avoir écrit en base, diffusé un fichier ou déclenché une opération avant son arrivée.

Une validation postérieure reste utile pour l’audit ou pour détecter une corruption. Elle ne transforme pas rétrospectivement l’action antérieure en décision conditionnée par l’intégrité. Si l’infrastructure perd le trailer, il faut enregistrer l’absence, pas présumer qu’un autre composant a validé silencieusement.

La persistance ouvre une autre période. Une concordance atteste les octets au point de contrôle ; elle ne promet pas que le stockage restera intact. Sans conservation de la totalité du contenu couvert et nouveau calcul, le condensat ne devient pas une preuve permanente. Le reçu devrait donc mentionner l’étape de traitement et l’instant logique, pas seulement l’algorithme.

Le condensat n’authentifie pas son auteur

RFC9530 circonscrit le mécanisme. Les champs ne protègent pas l’intégralité du message, ni automatiquement la méthode, l’URI cible, le statut ou toutes les métadonnées de représentation. Ils n’identifient pas l’émetteur, n’accordent pas un droit et ne chiffrent rien.

RFC9421 permet à une signature de message HTTP de couvrir un champ de condensat. Encore faut-il l’inclure explicitement dans la base de signature, avec les métadonnées pertinentes. La proximité visuelle entre une signature et un condensat ne crée aucun lien. La signature conserve en outre ses propres exigences de clé, de temps et de rejeu.

Un écart de condensat dit que les octets calculés diffèrent de la valeur fournie. Il ne dit pas qui a changé le message, pourquoi, ni si l’opération était autorisée. Cette modestie fonctionnelle est saine : l’intégrité des octets peut alors être combinée avec le transport, l’identité, l’autorisation et la conservation selon le risque réel.

Sources et limite des affirmations

Les exemples d’exploitation sont hypothétiques. L’article ne prétend mesurer ni taux de déploiement, ni incidents, ni attaques, ni coût de calcul, et ne fixe aucun seuil universellement sûr.