Résumé

  • Le RFC 9345 permet au détenteur d’un certificat de signer un objet limité dont la clé privée peut terminer une négociation TLS ou DTLS 1.3 compatible. Le pair vérifie toujours la chaîne et l’identité attendue ; le frontal reçoit un pouvoir de poignée de main, pas la propriété du certificat.
  • Sept jours constituent le plafond par défaut, non un canal de révocation instantanée. Une clé déléguée volée peut servir jusqu’à l’expiration et le protocole n’offre pas de retrait anticipé propre à un seul objet, sauf à révoquer le certificat signataire avec des conséquences plus larges.
  • Une preuve exploitable relie l’opt-in du certificat, l’objet signé, l’opération du signataire, la garde de la clé, les nœuds visés, la négociation du client, CertificateVerify, le repli, la reprise de session et le refus après expiration.

Une procuration qui tient dans un objet cryptographique

Le scénario commence sans déplacement de la clé la plus sensible. Le titulaire conserve la clé privée du certificat dans un service de signature. Il signe un Delegated Credential contenant une nouvelle clé publique, une échéance et un algorithme, puis le frontal reçoit ou génère la clé privée correspondante. Un client compatible annonce l’extension 34 ; le frontal peut alors produire CertificateVerify localement.

Ce résultat ressemble à une remise de certificat alors que l’architecture dit le contraire. Le frontal ne peut pas modifier les noms, renouveler auprès de l’autorité de certification, fabriquer une nouvelle délégation avec la clé courte ni obliger un ancien client à l’accepter. Son pouvoir existe pour une catégorie de négociations, tant que le certificat, le Credential, le temps, les algorithmes et la possession de clé concordent.

Le RFC 9345 n’a justement pas créé un certificat X.509 supplémentaire. La structure porte le strict nécessaire : fin de validité, algorithme attendu pour CertificateVerify et SubjectPublicKeyInfo. La signature du certificat couvre l’objet, le certificat encodé et un contexte distinct pour l’authentification client ou serveur. Une même délégation ne peut donc pas changer de rôle par simple copie.

Le certificat doit autoriser l’acte

La délégation ne découle pas de toute clé de certificat. Le certificat terminal doit contenir l’extension non critique DelegationUsage et l’usage digitalSignature. Le pair doit refuser si l’un manque. Ce consentement explicite réduit le risque qu’un accès temporaire à une clé ordinaire ou qu’un oracle hérité d’un ancien protocole soit transformé en fabrique de pouvoirs futurs.

Pour authentifier le serveur, le client annonce d’abord delegated_credential et les algorithmes qu’il accepte dans ClientHello. Le serveur peut ensuite placer un seul Credential dans le CertificateEntry terminal. Pour authentifier le client, le serveur doit l’avoir demandé dans CertificateRequest. Un objet non sollicité est une erreur de protocole, pas une amélioration tolérée.

Le vérificateur traite d’abord la chaîne et le nom attendu comme d’habitude. Il contrôle ensuite l’heure, la limite restante par défaut de sept jours, l’expiration du certificat, les deux relations d’algorithmes, l’extension d’autorisation et la signature du Credential. Ce n’est qu’alors que la clé déléguée vérifie CertificateVerify.

Il en ressort quatre actes distincts. L’AC émet le certificat. Son titulaire signe une permission réduite. Le frontal prouve la possession de la clé courte. L’application décide des droits associés au transport authentifié. Une poignée de main valide ne remplace pas une autorisation HTTP, financière ou administrative.

L’expiration limite la perte sans rappeler la clé

À défaut de profil différent, l’expiration ne peut se situer à plus de sept jours du temps courant du vérificateur ni après celle du certificat. Un opérateur peut choisir moins. Cloudflare documente, pour son produit Keyless, des Credentials qui deviennent invalides dans les 24 heures après désactivation. Cette politique plus courte ne change pas le plafond du protocole.

Elle ne crée pas davantage de bouton « retirer maintenant ». Le RFC 9345 ne définit pas de révocation anticipée individuelle. Arrêter les nouvelles signatures et supprimer la configuration du frontal empêche de nouveaux usages légitimes, sans reprendre une copie déjà volée. L’expiration reste le mécanisme ordinaire ; la révocation du certificat est une réponse plus large qui touche aussi les chemins non délégués.

La durée fait donc partie du budget de continuité. Une vie plus courte réduit l’intervalle d’usurpation, mais exige une signature, une distribution et une horloge plus fiables. valid_time se calcule depuis le notBefore du certificat, puis chaque pair juge avec sa propre heure. Une dérive à la frontière peut produire des refus que le serveur ne voit pas dans son inventaire.

La reprise de session ouvre un second chemin temporel. Un pair qui conserve la chaîne pour la revalider devrait conserver et revalider le Credential associé. Sinon, une décision fondée sur une délégation expirée peut survivre sans nouvelle poignée de main complète.

Deux façons de garder la clé courte

Le RFC 9677 rend concret le choix dans une interconnexion de CDN. Le CDN aval peut créer sa paire et ne transmettre que la clé publique à signer. La clé privée ne voyage pas, mais l’enrôlement de la clé publique doit être authentifié. Ou le CDN amont peut transmettre avec le Credential une clé privée chiffrée. L’émission est centralisée, au prix d’un ciphertext archivable et d’une clé de déchiffrement supplémentaire.

Le texte déconseille le transport de clés privées par l’interface de métadonnées. S’il a lieu, le chiffrement est obligatoire ; il n’apporte toutefois pas de confidentialité persistante si la clé de transport est compromise plus tard. L’expiration empêche une nouvelle négociation après la date, elle n’efface pas les archives.

Un autre arbitrage concerne le partage. Un Credential pour toute une région réduit la charge de signature et de rotation. Il agrandit le périmètre d’un vol et efface l’attribution à un nœud. Un Credential par frontal limite mieux, mais multiplie états, renouvellements et pannes possibles. La bonne granularité est celle que le système peut encore renouveler sous panne partielle, pas la plus fine sur un schéma.

Le repli reste une dépendance de premier rang

Le mécanisme ne fonctionne qu’en TLS/DTLS 1.3 et après annonce du pair. L’inscription IANA comme extension recommandée stabilise les règles ; elle ne mesure pas l’adoption. La documentation actuelle de Cloudflare cite Firefox 77 et suivants tout en indiquant que peu de clients et peu d’AC prennent en charge le dispositif.

Une flotte réelle demeure donc mixte. Les clients compatibles utilisent la clé courte. Les autres reviennent à une signature distante ou à un chemin qui expose la clé de certificat. La première solution ajoute latence et disponibilité du back-end ; la seconde recrée l’exposition de longue durée ; un certificat séparé ajoute un nouvel inventaire de renouvellement et de révocation.

Les tests BoringSSL illustrent cette discipline : TLS 1.2 n’utilise pas le Credential, les algorithmes de signature de l’objet et de CertificateVerify ne sont pas confondus, et un certificat ordinaire peut être choisi si aucune délégation ne convient. NSS sélectionne réellement la clé déléguée pour signer et la clé publique déléguée pour vérifier. Enregistrement, configuration et exécution sont trois preuves différentes.

Le registre minimal d’une délégation

Conserver l’empreinte, le numéro, les noms, la validité, KeyUsage et DelegationUsage du certificat ; le hash exact du Credential, celui de sa clé publique, son rôle, ses algorithmes et son échéance calculée ; l’approbateur et l’événement de signature par la clé longue.

Ajouter le mode de génération de la clé privée, la voie d’enrôlement ou de livraison, les nœuds autorisés, les accusés de déploiement et le degré de partage. Pour chaque négociation utile, distinguer l’annonce du client, l’objet sélectionné, les validations, CertificateVerify, la version et le repli.

La fin exige ses propres faits : arrêt de l’émission, retrait par nœud, dernier instant valide, décision sur la révocation du certificat, reprise de session et test négatif après l’échéance. Une configuration vide prouve un état local. Elle ne prouve pas que toutes les copies ont perdu leur pouvoir.

Sources