Résumé

  • La révision 02 permet à l’autorité de certification de comparer un enregistrement persistant à l’empreinte JWK SHA-256 de toute clé publique employée par le compte ACME pendant sa vie.
  • La rotation empêche l’ancienne clé privée d’authentifier de nouvelles requêtes, sans annuler automatiquement la preuve DNS qui lui était liée. Suppression du TXT, cache, persistUntil et expiration de l’autorisation suivent des délais différents.
  • La seule coupure immédiate à l’échelle du compte décrite par le projet est sa désactivation. Une organisation doit donc conserver un reçu retraçant la clé reconnue, l’observation DNS, le CAA, l’état du compte et la date ultime de réutilisation.

À 9 heures, une équipe remplace la clé de son compte ACME. Cinq minutes plus tard, elle supprime le TXT persistant. Les deux contrôles visibles disent « terminé » : l’ancienne clé privée n’est plus acceptée et le serveur faisant autorité ne publie plus la valeur.

Le pouvoir n’a pourtant pas nécessairement disparu. Une autorité de certification peut avoir validé le TXT avant sa suppression et conserver cette décision jusqu’à l’expiration de l’autorisation. Le projet ACME DNS Persistent Challenge transforme ainsi une preuve ponctuelle en état durable. Il faut suivre plusieurs horloges, pas une seule.

La révision 02 date du 20 septembre 2026. L’historique Datatracker la classe comme document actif du groupe de travail, à l’état I-D Exists. Le texte vise Standards Track, mais le Datatracker n’attribue encore ni statut projeté, ni shepherd, ni directeur de zone, ni étape IESG. Ce n’est donc ni un RFC, ni une Last Call, ni la preuve d’un déploiement par une autorité donnée.

Le format place sous _validation-persist une valeur dns-persist-01. Elle contient une empreinte JWK SHA-256 de 43 caractères, en base64url sans remplissage, puis un condensat liant nom de domaine, empreinte et URL du compte ACME. RFC 7638 fournit l’empreinte ; RFC 6920 encadre la représentation du condensat.

La CA essaie d’abord la clé courante. À défaut, elle remonte les clés publiques conservées pour ce compte, de la plus récente à la plus ancienne. C’est l’apport décisif de la nouvelle version : le diff 01–02 impose au serveur qui prend en charge ce mécanisme de retenir, pendant toute la vie du compte, l’empreinte de chacune de ses clés publiques. Le dépôt du groupe ACME documente le travail ; il ne vaut pas adoption opérationnelle.

Cette mémoire protège la continuité voulue par ACME. Une rotation normale ne devrait pas obliger l’opérateur DNS à réinstaller une délégation conçue pour durer. Surtout, le serveur ne garde pas l’ancienne clé privée. L’empreinte identifie la clé ayant participé au consentement ; elle ne peut pas fabriquer une signature.

La nuance est précisément celle que les inventaires de secrets masquent. Après le passage de K1 à K2, K1 ne peut plus ouvrir une session authentifiée. Mais une validation déjà acquise demeure rattachée au compte vivant. Et, lors d’une nouvelle consultation, le TXT calculé avec K1 peut encore correspondre puisque son empreinte figure dans l’historique. Le signataire actif a changé ; la concession DNS, elle, n’a pas forcément été retirée.

La suppression n’agit pas immédiatement non plus. Les résolveurs récursifs peuvent servir la réponse jusqu’à la fin du TTL. Ce TTL n’est pas la durée de réutilisation des données de validation : l’un gouverne le cache, l’autre la décision de la CA. persistUntil peut plafonner l’autorisation obtenue, mais effacer ensuite le TXT ou publier une date plus proche ne raccourcit pas rétroactivement une validation déjà enregistrée.

Il existe donc quatre temporalités : la clé qui authentifie le compte aujourd’hui ; la publication DNS et ses caches ; la durée pendant laquelle la CA réutilise le contrôle validé ; enfin la limite persistUntil déclarée au moment de l’observation. Un tableau de bord qui fusionne ces dates produit une illusion de révocation.

Le projet réserve une coupure franche : désactiver le compte ACME. Avant d’accepter la validation persistante, le serveur doit vérifier que le compte reste valide. La désactivation neutralise alors l’historique de clés. Elle est plus radicale que le retrait d’un TXT, puisqu’elle arrête tous les usages du compte. Un plan d’incident doit proposer les deux leviers et expliciter leur portée.

Le domaine est inclus par défaut dans le condensat. L’option domain_name=* autorise toutefois une valeur commune à plusieurs domaines pour un même compte et une même clé. Elle simplifie l’exploitation, mais augmente la corrélation visible et le rayon d’impact. La portée exacte, notamment pour les jokers, doit rester jointe à chaque décision d’émission.

Le CAA constitue un contrôle indépendant. Dans RFC 8657, accounturi porte l’URL réelle du compte ; ici, cette URL est intégrée au condensat du TXT. Une correspondance persistante ne remplace donc pas le traitement CAA, et l’autorisation CAA ne prouve pas la possession du TXT.

DNSSEC peut authentifier l’observation. Le projet recommande sa validation quand elle est disponible et prévoit l’échec du challenge si cette validation échoue. RFC 4033 décrit cette garantie d’origine et d’intégrité. Elle ne dit pas si la valeur cachée est toujours voulue, ni si le compte doit rester actif.

Une autre partie peut préconfigurer le record après qu’un POST-as-GET authentifié a confirmé la validité du compte. L’URL du compte et l’empreinte publique suffisent ; aucune clé privée n’est transmise. Cette séparation entre opérateur DNS et détenteur du compte est utile, à condition que l’approbation et l’installation soient attribuées à des acteurs nommés.

Au moment de cette analyse, les registres ACME de l’IANA ne contiennent pas dns-persist-01. Le vote SC-088v3 du CA/Browser Forum montre un intérêt industriel pour une méthode TXT persistante liée au compte. Son adoption unanime par les votants ne prouve ni le déploiement de ce projet IETF, ni l’identité des deux régimes.

Le bon artefact d’exploitation est un reçu couvrant toute la vie de l’autorisation : FQDN et portée de l’identifiant ; condensat observé, heure, vue faisant autorité et vue récursive ; TTL et horizon de cache ; autorité émettrice ; présence de domain_name=* ; compte protégé ; génération de clé courante ou historique reconnue ; état du compte ; résultats CAA et DNSSEC ; persistUntil ; expiration de l’autorisation ; commande et émission qui l’ont consommée.

Ce reçu permet enfin de dire ce qui a réellement été retiré. Il distingue une clé tournée mais encore reconnue par historique, une valeur effacée mais mise en cache, une ancienne validation encore réutilisable et une désactivation intervenue avant émission. Comparer un DNS actuel à un certificat décidé hier ne suffit pas.

Le projet peut encore évoluer. La frontière institutionnelle, elle, est déjà visible : la persistance déplace l’autorité d’une preuve en direct vers une histoire administrée. La rotation entretient cette histoire. Le retrait doit viser l’autorisation qui continue d’y vivre.

Sources