Résumé

  • Un DC valide autorise son détenteur à authentifier une connexion TLS ou DTLS 1.3 compatible dans les limites du certificat parent.
  • Il n'établit ni le contrôle du domaine, ni le pouvoir d'émission d'une AC, ni l'identité juridique, ni un mandat doté de son propre mécanisme de révocation anticipée.

Imaginons un tableau de contrôle observant un nœud CDN. Le nœud présente un DC valide, réussit une négociation TLS 1.3, puis le système le classe comme nouveau contrôleur du domaine. L'observation est exacte ; la conclusion ne l'est pas.

La RFC 9345 décrit un mécanisme plus étroit. Le titulaire d'un certificat signe une structure contenant une clé publique, un algorithme de signature et une durée courte. Le serveur frontal compatible peut alors terminer TLS sans recevoir la clé privée durable du certificat. La signature lie le DC au certificat d'entité finale complet et au rôle d'authentification client ou serveur.

Le client valide toujours la chaîne du certificat parent et compare le certificat d'entité finale à l'identité attendue. Ce certificat doit porter DelegationUsage et autoriser les signatures numériques. Le client vérifie aussi les algorithmes négociés, la signature du DC et l'intervalle de validité. Sauf profil contraire, la durée restante maximale est de sept jours et ne peut dépasser celle du certificat parent.

Ce contrôle prouve la possession d'une clé déléguée dans un cadre TLS déterminé. Il ne permet pas d'émettre un certificat public, de modifier le DNS, de prouver une relation d'entreprise ou de définir le détenteur légal du nom. Une négociation réussie n'est pas un titre de propriété.

La révocation renforce cette limite. La RFC 9345 n'ajoute pas de mécanisme autonome de révocation anticipée. L'expiration met fin au DC ; la révocation du certificat parent d'entité finale l'invalide implicitement. Si la clé privée durable utilisée pour signer les DC est compromise ou retirée, l'opérateur doit donc révoquer le certificat parent : le seul événement affectant la clé n'est pas un signal de révocation distinct dans le protocole. Une clé déléguée compromise peut servir à usurper l'identité de la partie délégataire jusqu'à l'expiration ou à la révocation du parent.

La courte durée réduit l'exposition sans supprimer l'exigence de garde.

Une reprise TLS 1.3 ne retransmet ni le certificat ni le DC. Si une implémentation ou une politique d'acceptation choisit de conserver et de revalider la chaîne d'origine lors de la reprise, elle devrait associer et revalider le DC d'origine. Il s'agit d'un traitement d'assurance conditionnel, et non d'une étape universelle du protocole.

Le reçu d'acceptation doit relier l'empreinte et la validité du certificat parent, DelegationUsage, l'empreinte de la clé publique déléguée, l'émetteur, le rôle client ou serveur, les algorithmes, l'intervalle, la cible de distribution, le dépositaire de la clé, la version TLS, la négociation observée, le traitement de la reprise, l'état de révocation du parent, le retrait et l'heure à laquelle chaque preuve a été observée. L'objectif n'est pas d'affaiblir le mécanisme, mais d'empêcher qu'un pouvoir de terminaison précis devienne une autorité générale par erreur d'inventaire.

Sources