1. Introduction

HTTP ne définit pas les moyens de protéger l'intégrité des données du contenu ou des représentations. Lorsque des messages HTTP sont transférés entre des points de terminaison, des fonctionnalités ou des propriétés de couche inférieure telles que les sommes de contrôle TCP ou les enregistrements TLS [TLS] peuvent fournir une certaine protection de l'intégrité. Cependant, l'intégrité orientée transport offre une utilité limitée car elle est opaque pour la couche application et ne couvre que l'étendue d'une seule connexion. Les messages HTTP voyagent souvent sur une chaîne de connexions distinctes. Entre les connexions, il existe une possibilité de corruption des données. Un mécanisme d'intégrité HTTP peut fournir aux points de terminaison, ou aux applications utilisant HTTP, les moyens de détecter la corruption des données et de choisir comment agir en conséquence. Un cas d'utilisation exemple est d'aider à la détection et au diagnostic des pannes au-delà des frontières du système.

Ce document définit deux mécanismes d'intégrité par condensat pour HTTP. Premièrement, l'intégrité du contenu, qui agit sur le contenu transporté (Section 6.4 de [HTTP]). Deuxièmement, l'intégrité des données de représentation, qui agit sur les données de représentation (Section 8.1 de [HTTP]). Cela prend en charge des cas d'utilisation avancés, tels que la validation de l'intégrité d'une ressource qui a été reconstruite à partir de parties récupérées à l'aide de plusieurs requêtes ou connexions.

Ce document rend obsolète la [RFC3230] et donc les champs HTTP Digest et Want-Digest ; voir la section 1.3.

1.1. Structure du document

Ce document est structuré comme suit :

• Nouvelles définitions de champs d'en-tête et de fin de requête et de réponse.

  • Section 2 (Content-Digest),
  • Section 3 (Repr-Digest), et
  • Section 4 (Want-Content-Digest et Want-Repr-Digest).

• Considérations spécifiques à l'intégrité des données de représentation.

  • Section 3.1 (Requêtes changeant l'état),
  • Section 3.2 (Content-Location),
  • L'annexe A contient des exemples concrets de données de représentation dans les échanges de messages, et
  • Les annexes B et C contiennent des exemples concrets des champs Repr-Digest et Want-Repr-Digest dans les échanges de messages.

• La section 5 présente les considérations relatives aux algorithmes de hachage et définit les procédures d'enregistrement pour les entrées futures.

1.2. Aperçu du concept

Les champs HTTP définis dans ce document peuvent être utilisés pour l'intégrité HTTP. Les expéditeurs choisissent un algorithme de hachage et calculent un condensat à partir d'une entrée liée au message HTTP. L'identifiant de l'algorithme et le condensat sont transmis dans un champ HTTP. Les destinataires peuvent valider le condensat à des fins d'intégrité. Les algorithmes de hachage sont enregistrés dans le registre "Hash Algorithms for HTTP Digest Fields" (voir la section 7.2).

La sélection des données sur lesquelles les condensats sont calculés dépend du cas d'utilisation des messages HTTP. Ce document fournit différents champs pour les données de représentation HTTP et le contenu HTTP.

Il existe des cas d'utilisation où un simple condensat des octets du contenu HTTP est requis. Le champ d'en-tête et de fin de requête et de réponse Content-Digest est défini pour prendre en charge les condensats de contenu (Section 6.4 de [HTTP]) ; voir la section 2.

Pour des cas d'utilisation plus avancés, le champ d'en-tête et de fin de requête et de réponse Repr-Digest (Section 3) est défini. Il contient une valeur de condensat calculée en appliquant un algorithme de hachage aux données de représentation sélectionnées (Section 8.1 de [HTTP]). Baser Repr-Digest sur la représentation sélectionnée permet de l'appliquer facilement aux cas d'utilisation où le contenu du message nécessite une certaine manipulation pour être considéré comme une représentation de la ressource ou si le contenu transmet une représentation partielle d'une ressource, comme les requêtes de plage (voir la section 14 de [HTTP]).

Content-Digest et Repr-Digest prennent en charge l'agilité des algorithmes de hachage. Les champs Want-Content-Digest et Want-Repr-Digest permettent aux points de terminaison d'exprimer leur intérêt pour Content-Digest et Repr-Digest, respectivement, et d'exprimer des préférences d'algorithme dans l'un ou l'autre.

Content-Digest et Repr-Digest sont collectivement appelés "Champs d'intégrité" (Integrity fields). Want-Content-Digest et Want-Repr-Digest sont collectivement appelés "Champs de préférence d'intégrité" (Integrity preference fields).

Les champs d'intégrité sont liés aux champs d'en-tête Content-Encoding et Content-Type. Par conséquent, une ressource donnée peut avoir plusieurs valeurs de condensat différentes lorsqu'elle est transférée avec HTTP.

Les champs d'intégrité s'appliquent au contenu du message HTTP ou aux représentations HTTP. Ils ne s'appliquent pas aux messages ou aux champs HTTP. Cependant, ils peuvent être combinés avec d'autres mécanismes qui protègent les métadonnées, tels que les signatures numériques, afin de protéger les phases d'un échange HTTP en tout ou en partie. Par exemple, les signatures de message HTTP [SIGNATURES] pourraient être utilisées pour signer les champs d'intégrité, fournissant ainsi une couverture pour le contenu HTTP ou les données de représentation.

Cette spécification ne définit pas de moyens pour l'authentification, l'autorisation ou la confidentialité.

1.3. Obsolescence de la RFC 3230

La [RFC3230] a défini les champs HTTP Digest et Want-Digest pour l'intégrité HTTP. Elle a également inventé les termes "instance" et "manipulation d'instance" afin d'expliquer des concepts, tels que les données de représentation sélectionnées (Section 8.1 de [HTTP]), qui sont maintenant plus universellement définis et mis en œuvre en tant que sémantique HTTP.

L'expérience a montré que les implémentations de la [RFC3230] ont interprété la signification de "instance" de manière incohérente, conduisant à des problèmes d'interopérabilité. Le problème le plus courant concerne l'erreur consistant à calculer le condensat en utilisant (ce que nous appelons maintenant) le contenu du message, plutôt qu'en utilisant (ce que nous appelons maintenant) les données de représentation comme cela était prévu à l'origine. Il est intéressant de noter que le temps a également montré qu'un condensat du contenu du message peut être bénéfique pour certains cas d'utilisation, il est donc difficile de détecter si la non-conformité à la [RFC3230] est intentionnelle ou non.

Afin de remédier aux incohérences et ambiguïtés potentielles entre les implémentations de Digest et Want-Digest, ce document rend obsolète la [RFC3230]. Les champs d'intégrité (sections 2 et 3) et les champs de préférence d'intégrité (section 4) définis dans ce document sont mieux alignés avec la sémantique HTTP actuelle et ont des noms qui articulent plus clairement les utilisations prévues.

1.4. Conventions de notation

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

Ce document utilise l'Augmented BNF défini dans la [RFC5234] et mis à jour par la [RFC7405]. Cela inclut les règles CR (retour chariot), LF (saut de ligne) et CRLF (CR LF).

Ce document utilise la terminologie suivante de la section 3 de [STRUCTURED-FIELDS] pour spécifier la syntaxe et l'analyse : Booléen (Boolean), Séquence d'octets (Byte Sequence), Dictionnaire (Dictionary), Entier (Integer) et Liste (List).

Les définitions "représentation", "représentation sélectionnée", "données de représentation", "métadonnées de représentation", "agent utilisateur" et "contenu" dans ce document doivent être interprétées comme décrit dans [HTTP].

Ce document utilise les stratégies de pliage de ligne décrites dans [FOLDING].

Les noms des algorithmes de hachage respectent la casse utilisée dans leur document de définition (par exemple, SHA-1, CRC32c).

Les messages HTTP indiquent les algorithmes de hachage à l'aide d'une clé d'algorithme (Algorithm Key) (algorithmes). Lorsque le document fait référence à une clé d'algorithme en prose, elle est citée (par exemple, "sha", "crc32c").

Le terme "somme de contrôle" (checksum) décrit la sortie de l'application d'un algorithme à une séquence d'octets, tandis que "condensat" (digest) n'est utilisé qu'en relation avec la valeur contenue dans les champs.

"Champs d'intégrité" (Integrity fields) est le terme collectif pour Content-Digest et Repr-Digest.

"Champs de préférence d'intégrité" (Integrity preference fields) est le terme collectif pour Want-Repr-Digest et Want-Content-Digest.