Résumé

  • RFC 9677 distingue l’annonce de capacité FCI.DelegatedCredentials de la remise effective des éléments dans MI.DelegatedCredentials ; aucune des deux ne constitue un accusé d’installation par serveur.
  • Le nombre annoncé est un plafond et non un inventaire du parc ; une même identité déléguée peut servir plusieurs terminaisons, tandis que certaines terminaisons peuvent rester sur une voie de secours.
  • La preuve exploitable doit relier l’émission, l’origine de la clé privée, la version des métadonnées, l’état de chaque nœud, l’offre du client, la négociation TLS et le résultat HTTP.

Une rotation peut être ponctuelle et pourtant inachevée

Supposons que le CDN amont publie les nouveaux éléments à 23 h 55. Le CDN aval récupère l’objet à 23 h 56 et renvoie un succès. À minuit, presque tout le parc utilise le successeur. Un site périphérique, encore sélectionné par le routage, n’a pas rechargé son magasin de secrets. Le transfert a réussi ; le changement de service n’a pas convergé.

RFC 9677 ne masque pas cette différence. Son objet de métadonnées apporte une convention commune à deux opérateurs qui doivent échanger des justificatifs délégués définis par RFC 9345. Il réduit une difficulté réelle : déléguer la terminaison HTTPS sans remettre partout la clé privée durable du certificat. Mais le document n’ajoute pas un protocole d’acquittement par terminaison entre la récupération des métadonnées et la poignée de main du client.

La bonne lecture n’est donc pas « le standard oublie une étape ». Le standard s’arrête à une frontière cohérente. C’est au système d’exploitation du CDN de rendre visibles les étapes qui suivent.

L’annonce de capacité ne réserve rien

Le CDN aval peut d’abord déclarer qu’il comprend MI.DelegatedCredentials. Il peut aussi publier FCI.DelegatedCredentials, avec le nombre maximal de justificatifs pris en charge et, éventuellement, une clé publique PrivateKeyEncryptionKey destinée à chiffrer les clés privées transportées.

Ce nombre aide le CDN amont à ne pas envoyer un ensemble impossible à traiter. Il ne décrit pas nécessairement le nombre de serveurs. Le texte précise qu’il y correspond souvent, mais pas obligatoirement. Le CDN aval peut déployer un seul justificatif sur plusieurs terminaisons, ou en affecter un distinct à chacune. Le plafond ne dit ni combien de places sont libres, ni quelles machines sont actives, ni quelle empreinte géographique a convergé.

Cette nuance rejoint la différence entre capacité annoncée et capacité engagée. Pourtant, l’enjeu est ici cryptographique : interpréter le plafond comme un inventaire conduit à inventer une carte de déploiement que le message ne contient pas.

Le contenu livré peut suivre deux chemins de garde

MI.DelegatedCredentials contient un tableau. Chaque entrée porte un CertificateEntry encodé en base64, avec la structure déléguée de RFC 9345. La clé privée correspondante est facultative. Lorsqu’elle est incluse, elle doit être placée dans une enveloppe JWE compacte, chiffrée pour la clé annoncée par le CDN aval.

Lorsqu’elle est absente, l’hypothèse n’est pas que la clé n’existe pas. Le CDN aval peut avoir généré la paire localement et communiqué la clé publique au CDN amont par un autre canal. Cette variante limite la circulation du secret, mais elle crée un lien externe que les métadonnées seules ne peuvent attester.

Il faut donc conserver la provenance : paire générée où, clé publique transmise par quel canal, justificatif signé à partir de quelle demande, enveloppe destinée à quel identifiant de clé, déchiffrement accompli par quel composant. Une case « reçu » ne répond à aucune de ces questions.

Une enveloppe chiffrée n’efface pas le risque historique

RFC 9677 déconseille de transmettre la clé privée par l’interface de métadonnées. Si ce choix est fait, la force de la clé JWE doit être au moins égale à celle du secret protégé. Le chiffrement protège l’échange, mais il n’offre pas de confidentialité persistante : une compromission ultérieure de la clé de déchiffrement du CDN aval peut ouvrir les enveloppes capturées.

La courte durée du justificatif réduit la fenêtre d’usurpation. Elle ne prouve ni l’effacement des copies, ni l’absence de capture, ni la rotation du destinataire JWK, ni l’import dans un composant matériel approuvé. Un journal sûr doit garder les empreintes, algorithmes, identifiants, instants et décisions, jamais la clé privée elle-même.

À l’inverse, le justificatif public sans sa clé correspondante reste inutilisable pour signer CertificateVerify. Une charge utile valide peut donc être parfaitement reçue et néanmoins échouer au moment du test local.

Le client garde le dernier mot cryptographique

RFC 9345 impose une négociation. Le client annonce l’extension et les schémas de signature qu’il accepte. Le serveur ne doit pas présenter un justificatif délégué à un client qui n’en a pas annoncé la prise en charge. Le certificat reste validé, l’identité de service reste vérifiée, la signature de délégation et les bornes temporelles restent contrôlées.

Par défaut, la durée maximale est de sept jours et le justificatif ne peut dépasser la fin du certificat délégant. Il est aussi lié à un schéma de signature pour la poignée de main. Un objet reçu peut ainsi être trop vieux pour ce serveur, incompatible avec l’offre de ce client ou rattaché à un certificat qui ne permet pas cette délégation.

Même face à un client compatible, le serveur peut choisir de ne pas présenter le justificatif. Un chemin par certificat ordinaire ou signature distante peut rester disponible pour compatibilité et secours. Une connexion TLS réussie démontre alors la disponibilité du chemin observé, pas nécessairement l’usage du mécanisme délégué.

Entre récupération et poignée de main, le parc travaille

Le schéma d’appel de RFC 9677 enchaîne l’annonce, l’acquisition, la connexion du client et le renouvellement. Entre l’acquisition et la connexion se trouvent les étapes propres à l’opérateur : validation, déchiffrement, dépôt sécurisé, génération de configuration, canari, diffusion, rechargement, contrôle de santé et changement de routage.

Ces étapes ne sont pas atomiques à l’échelle mondiale. Une file peut accepter le travail avant son exécution. Un serveur peut stocker le nouveau secret sans l’activer. Une terminaison correcte peut rester sans trafic, tandis qu’une terminaison périmée reçoit encore une part faible mais réelle des clients.

La convergence doit donc être mesurée sur un ensemble nommé. Pour chaque nœud attendu : empreinte installée, état actif, dernière observation, cohorte, route, échec et solution de repli. Le pourcentage global n’a de sens qu’avec ce dénominateur et la liste des exclusions.

L’expiration transforme une divergence en refus de service

L’objet FCI ne gère ni l’expiration ni le renouvellement. RFC 9677 demande au CDN amont de surveiller les éléments fournis et de les renouveler à temps. Un serveur aval qui ne possède que des justificatifs expirés doit refuser les nouvelles connexions qui exigent un justificatif à jour.

Ce refus est une preuve locale forte : à cet instant, ce nœud ne pouvait pas satisfaire cette voie. Il ne décrit pas les autres nœuds. Certains peuvent avoir le successeur, d’autres utiliser encore le prédécesseur dans une fenêtre de chevauchement, d’autres avoir basculé sur le secours ou été retirés du routage.

La faible durée crée donc un échange économique. Elle limite l’exposition après vol, mais augmente le rythme des rotations et le nombre d’occasions où une défaillance silencieuse devient une panne. Le bon objectif porte sur la capacité utilisable du successeur sur tout l’ensemble routé avant la fin du rôle du prédécesseur, et non sur la seule date d’émission.

Construire un registre à dix reçus

Le premier reçu concerne le certificat délégant : empreinte, identité, autorisation et validité. Le deuxième décrit le justificatif : empreinte, clé publique, algorithme et expiration. Le troisième fixe l’origine de la clé privée. Le quatrième conserve la capacité FCI, l’empreinte concernée et la clé de chiffrement annoncée.

Le cinquième prouve la récupération de la version exacte des métadonnées. Le sixième vient des terminaisons qui ont validé et installé la paire. Le septième décrit la convergence, y compris les nœuds en échec, drainés ou sur secours. Le huitième enregistre la décision de routage qui a choisi une terminaison.

Le neuvième est la poignée de main observée : offre du client, version TLS, schéma choisi, chaîne, extension et résultat de vérification. Le dixième est le résultat HTTP et applicatif. Chacun répond à une question différente. Les fusionner produit un statut commode et une enquête impossible.

Donner un sens précis aux échecs

Si la capacité n’est pas annoncée, utiliser une voie explicitement prise en charge. Si le plafond est insuffisant, réduire l’ensemble ou changer d’architecture ; ne pas parler de réservation. Si la clé correspondante manque ou si le JWE ne se déchiffre pas, isoler l’entrée et préserver la trace de décision.

Un parc mixte doit conserver un secours vérifié ou retirer les nœuds périmés du trafic. Les canaris doivent inclure des clients compatibles et non compatibles, plusieurs schémas, des justificatifs proches de l’expiration et chaque cohorte de routage. Un succès par le chemin classique doit apparaître comme un succès de secours, pas comme une validation de la délégation.

En cas de compromission de la clé de chiffrement aval, la réponse couvre les nouveaux secrets et les anciennes enveloppes potentiellement capturées. La durée de sept jours borne l’usage du justificatif ; elle n’annule pas l’enquête de garde.

Respecter la portée, c’est renforcer le standard

RFC 9677 n’est ni une autorité de certification, ni un mécanisme de révocation, ni un algorithme de routage, ni une attestation de parc. Il crée des objets interopérables pour une transmission qui, sans eux, serait propriétaire et plus opaque.

La doctrine des couches de réalité de Heng Lu apporte ici une règle simple : une intention configurée reste une intention jusqu’à ce que le code en production fournisse son propre reçu. La spécification minimale coordonne l’échange ; les choix locaux doivent assumer l’activation, le secours, la conservation des preuves et l’autorité d’incident.

Le CDN peut donc affirmer honnêtement : « l’objet a été remis ». Pour dire « la périphérie l’a servi », il lui faut une autre preuve.

Sources