Résumé

  • TLS 1.3 emploie certificate_request_context pour rattacher le bloc d’authentification du client à un CertificateRequest précis, notamment lorsque plusieurs réponses postérieures à la poignée de main peuvent arriver dans un ordre différent. L’unicité dans la connexion ne définit aucune portée d’autorisation.
  • Un reçu défendable relie ce contexte et la preuve de possession à des éléments séparés : politique de chaîne de certification, principal applicatif, ressource, décision, expiration et contrôle de révocation. Le lien ne doit pas permettre au contexte opaque de remplacer ces décisions.

Un service envoie deux demandes d’authentification après l’établissement d’une même connexion. Dans sa mémoire, il appelle la première « facturation » et la seconde « administration », puis inscrit deux valeurs aléatoires dans certificate_request_context. Le client répond. Si le journal durable ne conserve ensuite que la valeur et la réussite de TLS, il devient impossible de savoir quel principal avait reçu quel droit. La corrélation cryptographique a survécu ; la décision applicative a disparu.

La RFC 9846, Proposed Standard de juillet 2026 pour TLS 1.3, décrit le champ sans ambiguïté. Un message CertificateRequest contient un contexte opaque, puis des extensions qui précisent les paramètres de l’authentification demandée. Le client recopie le contexte dans son message Certificate. Le serveur peut ainsi reconnaître la requête à laquelle répond le bloc reçu.

La valeur peut mesurer de zéro à 255 octets et doit être unique dans la connexion. Cette unicité empêche qu’un CertificateVerify du client soit rejoué comme réponse à une autre demande sur le même canal. Dans la poignée de main initiale, le champ est vide. Une valeur non vide est réservée aux échanges d’authentification postérieurs prévus par le standard.

Pour ces échanges ultérieurs, le serveur devrait aussi rendre le contexte imprévisible, par exemple en le tirant aléatoirement. Le but est d’empêcher une personne disposant temporairement de la clé privée du client de préparer à l’avance des CertificateVerify valables pour de futures demandes prévisibles. L’aléa protège le rattachement de la preuve. Il ne transforme pas les octets en capacité secrète ni en permission métier.

Cette précision compte parce qu’une valeur opaque invite les équipes à lui donner un nom local. Il est possible de l’associer temporairement à une étape de flux, mais cette association n’appartient pas à TLS. Une autre installation peut produire une valeur de même taille pour un usage différent. La portée d’unicité est la connexion, pas l’organisation, le compte, la ressource ou la durée d’une session.

Les extensions de la demande décrivent des contraintes TLS. signature_algorithms est obligatoire ; des autorités de certification acceptables, filtres d’identifiants d’objet ou règles sur les signatures de certificats peuvent aussi être indiqués. Ces paramètres orientent le matériel que le pair peut présenter. Ils ne disent toujours pas qu’une opération précise est permise sur une ressource précise.

Si le client accepte de s’authentifier après une demande autorisée, il envoie Certificate, CertificateVerify et Finished. La signature prouve la possession de la clé privée correspondant au certificat et couvre le transcript pertinent. Finished clôt le bloc d’authentification dans l’état TLS. Ces preuves sont fortes, mais leur force ne leur donne pas un objet plus large.

Le client peut refuser en envoyant un message Certificate vide suivi de Finished. TLS sait alors qu’aucun certificat n’a été fourni pour cette demande. L’application doit encore décider si un fonctionnement anonyme reste possible, si un autre justificatif est admis ou si la connexion doit prendre fin. Un certificat vide n’est ni une déconnexion de compte, ni un retrait de consentement, ni une interdiction durable universelle.

La temporalité explique la nécessité du contexte. L’accès à une carte ou la sollicitation d’une personne peut retarder la réponse. Plusieurs demandes rapprochées peuvent ainsi recevoir des réponses dans un ordre différent de leur émission. La valeur recopiée donne au serveur une clé de corrélation fiable, sans ériger l’ordre d’arrivée en identité.

La possibilité elle-même dépend d’une annonce préalable. Le serveur ne peut envoyer un CertificateRequest postérieur que si le client a inclus l’extension vide post_handshake_auth. Sans elle, la demande est un message inattendu et déclenche une alerte fatale. Mais l’annonce de capacité ne suffit pas à autoriser l’usage dans tous les protocoles supérieurs.

La RFC 9113 en donne la preuve nette. HTTP/2 interdit au serveur d’envoyer un CertificateRequest TLS 1.3 après la poignée de main et impose au client de le traiter comme une erreur de connexion. L’interdiction vaut même si le client a annoncé post_handshake_auth, puisque cette annonce peut servir à d’autres protocoles applicatifs. La possibilité TLS ne supplante pas la règle HTTP/2.

L’acceptabilité du certificat constitue encore une autre couche. La RFC 5280 définit la validation de chemin comme la vérification d’un lien entre un nom de sujet, ou un nom alternatif, et une clé publique selon les contraintes des certificats, l’ancre choisie et les entrées de la partie qui se fie au résultat. Le choix de l’ancre est une politique locale, et une application peut resserrer l’ensemble des chemins acceptés.

Il faut donc distinguer possession, identité et autorisation. CertificateVerify peut montrer que le répondant contrôle une clé. La validation de chemin peut établir qu’un cadre de confiance choisi lie cette clé à un nom sous certaines contraintes. L’application peut enfin mapper ce nom ou cette clé à un principal, puis décider de ses droits. Le contexte correct ne répare pas l’échec d’un prédicat ultérieur.

La RFC 9525 montre que les protocoles applicatifs doivent préciser leur manière de vérifier l’identité d’un service avec TLS. Son objet principal est l’identité du serveur, pas une politique générale d’autorisation des clients. La leçon de structure demeure : TLS offre des mécanismes d’authentification ; le profil d’usage fixe la référence d’identité et les conséquences d’une correspondance.

OAuth fournit un exemple applicatif utile. La RFC 8705 distingue l’authentification mutuelle TLS du client des jetons d’accès liés à un certificat. Un serveur d’autorisation applique sa politique au client_id, vérifie le certificat attendu et peut lier un jeton à la possession de la clé. Au serveur de ressources, le jeton porte toujours la décision d’autorisation ; le certificat seul ne détermine pas la ressource permise.

La RFC 6749 définit les habilitations, jetons et portées au niveau OAuth. La RFC 7662 décrit l’introspection et notamment l’état actif d’un jeton. Ni la portée, ni l’audience, ni l’expiration, ni l’activité courante ne se trouvent dans le contexte de la demande TLS.

Le contexte ne convient pas davantage comme identifiant de session. Une authentification postérieure survient à un instant d’une connexion. L’application choisit si elle élève une session, seulement les futures requêtes, un sous-ensemble d’opérations, et pendant combien de temps. Réutiliser les octets opaques comme session masque le début, le périmètre et la fin de l’autorisation.

Le multiplexage aggrave le risque : plusieurs opérations applicatives peuvent être en cours pendant qu’une authentification attend sa réponse, alors que la demande TLS concerne la connexion. Un protocole qui l’autorise doit définir à quelles opérations le résultat s’applique. HTTP/2 préfère interdire l’échange. Le contexte, à lui seul, ne peut inventer cette frontière.

La révocation et la fraîcheur restent également hors du champ. Une chaîne peut être acceptable à l’instant de sa validation, tandis que la politique locale décide des informations de révocation à consulter. Un jeton peut devenir inactif avant sa date nominale. Un mapping de principal peut changer. L’unicité dans la connexion ne maintient aucune de ces horloges à jour.

La RFC 9325 rassemble des recommandations pour un usage et un déploiement sûrs de TLS. Elles améliorent la configuration du protocole sans définir un modèle d’autorisation métier universel. De même, le registre TLS de l’IANA attribue des codes et un vocabulaire, pas des rôles dans une application.

Enfin, le registre de publication de la RFC 9846 fixe son statut et la page des errata permet de suivre les corrections. La RFC 8446 conserve le texte remplacé. Ces sources identifient la règle retenue ; elles ne démontrent aucune adoption, conduite de fournisseur ou défaillance observée.

Sources