Summary

  • La version du 27 octobre du projet dns-account-01 est en dernier appel de l’IESG jusqu’au 10 novembre. Elle attribue un nom DNS distinct à chaque compte ACME pour que plusieurs systèmes puissent déléguer leur validation du même domaine.
  • Ce nom dépend du hachage de l’URL complète du compte. Changer la clé conserve le nom ; déplacer le service ACME vers une autre URL peut rendre les enregistrements préparés inutilisables.

Le problème tient dans _acme-challenge.example.org. Le défi dns-01 défini par RFC 8555 accepte plusieurs valeurs TXT, mais deux équipes indépendantes qui veulent chacune déléguer la validation par CNAME arrivent au même propriétaire DNS. Un seul CNAME peut occuper ce nom. La seconde équipe doit alors dépendre du résolveur de défi de la première, ou changer de méthode.

Le projet IETF du 27 octobre déplace la séparation dans le nom lui-même. Il calcule SHA-256 sur l’URL du compte ACME, retient les dix premiers octets et les encode en Base32 avant _acme-challenge. Son exemple donne _ujmmovf2vn55tgye._acme-challenge.example.org. Chaque compte reçoit ainsi une branche susceptible de pointer par CNAME vers son propre système. Le serveur ACME suit ce chemin, lit le TXT et vérifie l’empreinte de l’autorisation liée au jeton du défi.

La stabilité de cette branche dépend d’un détail administratif devenu technique. La section 3.5 inclut le protocole, le nom d’hôte, le port et tout le chemin de l’URL du compte. Le renouvellement de clé laisse cette URL intacte. Une migration du serveur qui la modifie oblige à recalculer les noms DNS ; le texte demande au serveur de conserver les anciens identifiants lorsque c’est possible. Le registre de suivi de l’IETF place la version 04 en dernier appel, avec une échéance au 10 novembre et un statut visé de norme proposée.

Il manque encore un inventaire public des serveurs et clients qui déploieront ce défi, ainsi qu’un retour d’expérience sur la conservation des URL de compte pendant une migration réelle.