1.2. Terminology and Applicability (Terminologie et applicabilité)

1.2. Terminology and Applicability (Terminologie et applicabilité)

Ce document utilise la terminologie suivante de la Section 3 de [STRUCTURED-FIELDS] pour spécifier la syntaxe et l'analyse : List (liste) et Byte Sequence (séquence d'octets).

Des expressions comme "authentification par certificat client TLS" ou "TLS mutuellement authentifié" sont utilisées tout au long de ce document pour faire référence au processus par lequel, en plus de l'authentification normale du serveur TLS avec un certificat, un client présente son certificat X.509 [RFC5280] et prouve la possession de la clé privée correspondante à un serveur lors de la négociation d'une connexion TLS ou de la reprise d'une telle connexion. Dans les versions contemporaines de TLS [TLS] [TLS1.2], l'authentification mutuelle nécessite que le client envoie les messages Certificate et CertificateVerify pendant la poignée de main (handshake) et que le serveur vérifie les messages CertificateVerify et Finished.

HTTP/2 restreint la renégociation TLS 1.2 (Section 9.2.1 de [HTTP/2]) et interdit l'authentification post-handshake TLS 1.3 (Section 9.2.3 de [HTTP/2]). Cependant, ils sont parfois utilisés pour implémenter l'authentification réactive par certificat client dans HTTP/1.1 [HTTP/1.1] où le serveur décide de demander un certificat client en fonction de la requête HTTP. Les données d'application HTTP envoyées sur une telle connexion après réception et vérification du certificat client sont également mutuellement authentifiées et donc appropriées pour les mécanismes décrits dans ce document. Avec l'authentification post-handshake, il existe également la possibilité, bien qu'improbable en pratique, de plusieurs certificats et chaînes de certificats provenant du client sur une connexion. Dans ce cas, seuls le certificat et la chaîne de la dernière authentification post-handshake doivent être utilisés pour les champs d'en-tête décrits ici.