1. Introduction (Vue d'ensemble)

1. Introduction

L'intégrité des messages et l'authenticité sont des propriétés de sécurité essentielles au fonctionnement sûr de nombreuses applications HTTP. Les développeurs d'applications s'appuient en général sur la couche transport pour obtenir ces propriétés, en faisant tourner leur application sur TLS [TLS]. TLS ne garantit toutefois ces propriétés que sur une seule connexion TLS, et le chemin entre le client et l'application peut être composé de plusieurs connexions TLS indépendantes (par exemple si l'application est derrière une passerelle terminant TLS ou si le client est derrière un équipement d'inspection TLS). Dans de tels cas, TLS ne peut pas garantir l'intégrité ni l'authenticité de bout en bout entre le client et l'application. De plus, certains environnements d'exécution rendent peu pratique l'usage de TLS (comme la présentation de certificats client depuis un navigateur) ou l'usage de fonctionnalités nécessaires à l'authenticité des messages. En outre, certaines applications exigent de lier une clé propre à l'application, distincte des certificats TLS en cours d'utilisation. Par conséquent, bien que TLS puisse satisfaire les besoins d'intégrité et d'authenticité pour de nombreuses applications HTTP, ce n'est pas une solution universelle.

De plus, nombre d'applications doivent pouvoir générer et vérifier des signatures malgré une connaissance incomplète du message HTTP tel qu'il apparaît sur le fil, en raison de bibliothèques, de mandataires ou de cadres applicatifs qui modifient ou masquent des parties du message au moment de la signature ou de la vérification. Ces applications ont besoin d'un moyen de protéger les parties du message les plus pertinentes pour l'application sans violer le cloisonnement et l'abstraction.

Enfin, des mécanismes de signature fondés sur des objets, tels que JSON Web Signature [JWS], exigent la transmission intacte des informations exactes qui ont été signées. Lorsqu'on applique de telles technologies à un message HTTP, des éléments du message HTTP doivent être dupliqués dans la charge utile de l'objet, directement ou par inclusion d'un hachage. Cette pratique introduit de la complexité, car les informations répétées doivent être soigneusement vérifiées pour cohérence lors de la vérification de la signature.

Ce document définit un mécanisme pour fournir l'intégrité et l'authenticité de bout en bout pour des composants d'un message HTTP au moyen d'une signature détachée sur les messages HTTP. Le mécanisme permet aux applications de créer des signatures numériques ou des codes d'authentification de message (MAC) sur seulement les composants du message qui sont significatifs et adaptés à l'application. Des règles de canonisation strictes garantissent que le vérificateur peut vérifier la signature même si le message a été transformé de nombreuses façons autorisées par HTTP.

Le mécanisme de signature décrit dans ce document se compose de trois parties:

• Une nomenclature commune et un ensemble de règles de canonisation pour les différents éléments de protocole et autres composants des messages HTTP, utilisés pour créer la base de signature (signature base) (Section 2).

• Des algorithmes pour générer et vérifier des signatures sur des composants de message HTTP à partir de cette base de signature par application de primitives cryptographiques (Section 3).

• Un mécanisme pour attacher une signature et des métadonnées associées à un message HTTP et pour analyser les signatures et métadonnées attachées à partir des messages HTTP. À cette fin, ce document définit les champs Signature-Input et Signature (Section 4).

Ce document fournit aussi un mécanisme pour négocier l'usage de signatures dans un ou plusieurs messages ultérieurs via le champ Accept-Signature (Section 5). Ce mécanisme de négociation facultatif peut être utilisé conjointement avec des signatures opportunistes ou pilotées par l'application, de part et d'autre.

Les mécanismes définis dans ce document sont des outils importants pour construire un mécanisme de sécurité global pour une application. Cette boîte à outils offre des capacités puissantes mais ne suffit pas à constituer une histoire de sécurité complète. En particulier, les exigences énumérées à la Section 1.4 et les considérations de sécurité abordées à la Section 7 sont d'une grande importance pour tous les implémenteurs de cette spécification. Par exemple, cette spécification ne définit pas de moyen de couvrir directement le contenu du message HTTP (défini à la Section 6.4 de [HTTP]); elle s'appuie plutôt sur la spécification Digest [DIGEST] pour fournir un hachage du contenu du message, comme indiqué à la Section 7.2.8.