Résumé

  • draft-skoglund-epp-registry-lock-00 propose qu’une modification d’un domaine verrouillé reste en attente jusqu’à l’accord d’un ou plusieurs contacts désignés, dans un délai configuré.
  • La politique expose un nombre d’approbations et le message final peut nommer les identifiants qui ont approuvé, mais ni l’assurance d’identité, ni le défi, ni l’indépendance des canaux ne sont normalisés.
  • Une trace de cérémonie d’approbation doit relier état initial et état demandé, domaines de contrôle distincts, défis, exceptions, heures et résultat final. Cette trace est une proposition de gouvernance, pas une obligation IETF.

Pour un domaine critique, demander deux accords paraît plus sûr qu’en demander un. Mais si les deux contacts utilisent le même espace de messagerie, le même service de récupération et des téléphones administrés par la même équipe, l’attaquant ne rencontre pas deux autorités. Il rencontre une seule frontière technique qui produit deux réponses.

Le verrouillage au niveau du registre est précisément destiné à ajouter une autre frontière que celle du compte registrar. Une modification de serveurs de noms peut détourner le trafic ; un changement de titulaire ou de prestataire peut déplacer le contrôle. L’intervention du registre réduit le risque qu’un seul identifiant compromis suffise. Automatiser cette intervention ne doit pas effacer la séparation qui lui donne sa valeur.

La révision 00 a été publiée le 30 juin 2026. Son en-tête rendu mentionne la voie de normalisation, tandis que Datatracker la qualifie d’Internet-Draft individuel, sans flux ni statut RFC visé, et sans valeur formelle dans le processus IETF. Il ne s’agit donc ni d’un RFC ni d’un consensus établi de REGEXT.

Une commande ouvre un épisode, elle ne termine plus l’action

Le projet part de services existants, encore différents et souvent manuels, puis introduit une extension du mappage de domaine EPP. Une fois le verrou posé, le domaine doit porter serverDeleteProhibited. Pendant l’attente d’une autorisation, il doit porter serverPendingUpdate.

La création du verrou ou la modification d’un domaine verrouillé renvoie le code 1001 : la commande est acceptée, mais une action reste à accomplir. Si l’autorisation arrive avant l’échéance, un message de file signale le succès ; sinon, un autre signale l’échec.

Cette temporalité est le cœur du mécanisme. Le clTRID initial et le svTRID ne décrivent plus à eux seuls une transition achevée. Le client doit relier la demande en attente au message ultérieur. Le résultat de file indique le domaine, l’opération, un identifiant serveur antérieur et les identifiants des contacts ayant approuvé. Le protocole de base ajoute date de file et nouveaux identifiants de transaction.

Cette chaîne prouve qu’un serveur a compté des réponses. Elle ne raconte pas comment ces réponses ont été obtenues.

La pluralité des lignes n’est pas l’indépendance du pouvoir

La politique peut contenir un délai et un entier positif indiquant le nombre d’accords, écrit quorom dans la révision 00. Le serveur peut limiter les valeurs et le nombre de contacts liés au domaine.

Ce chiffre évite un désaccord élémentaire sur le nombre nécessaire. Il n’établit pourtant aucune séparation entre personnes, employeurs, appareils, fournisseurs d’identité ou voies de récupération. Trois fiches peuvent pointer vers une boîte partagée ; deux sociétés peuvent déléguer leur authentification au même prestataire ; plusieurs numéros peuvent être gérés par un seul administrateur.

La pluralité est une propriété de base de données. L’indépendance est une propriété d’architecture : un seul incident, ordre ou mécanisme de récupération ne doit pas satisfaire tous les accords requis. Un opérateur peut légitimement laisser cette règle hors du protocole, mais il ne peut alors présenter le seul nombre comme preuve d’un contrôle à plusieurs personnes.

Les mots « e-mail » et « jeton » ne sont pas des niveaux d’assurance

Chaque contact possède un identifiant et peut porter une méthode. Le projet propose les valeurs e-mail, SMS, lettre, téléphone et jeton, tout en permettant d’autres valeurs.

Ces mots décrivent un canal, pas la force de la vérification. Un e-mail peut être un lien signé, une simple réponse ou un échange avec le support. Un SMS ne dit rien de la réattribution du numéro. Un jeton peut être matériel ou transférable. Un appel ne prouve pas qui répond, et une lettre n’est sûre que si l’adresse, le défi et le destinataire sont eux-mêmes maîtrisés.

Le texte ne normalise ni contenu du défi, ni liaison cryptographique avec la modification, ni anti-rejeu, ni enrôlement, ni preuve d’identité, ni récupération. Cette réserve est compréhensible pour un premier mappage. Elle limite néanmoins la portée du champ approvedBy : il atteste la décision selon la procédure privée du registre, pas une assurance universelle.

Geler une fiche de contact ne suffit pas à geler l’autorité

La modification et la suppression d’une fiche utilisée comme contact de verrouillage doivent être rejetées. Cela bloque une attaque évidente : remplacer l’adresse puis approuver par la nouvelle voie.

Mais l’extension permet aussi d’ajouter ou retirer des contacts et de changer le délai ou le nombre requis. La question devient récursive : quelle ancienne autorité doit approuver la transformation de l’ensemble des autorités ?

Retirer le seul contact extérieur à l’organisation n’est pas une mise à jour ordinaire. Réduire le quorum ou raccourcir le délai peut affaiblir la protection avant la modification suivante. La décision doit donc être évaluée sous la politique et la liste qui existaient à l’ouverture, puis conserver l’état avant et après. Une règle ne devrait pas se réécrire elle-même au moment où elle juge sa propre modification.

Les exceptions dessinent le véritable périmètre

Le verrou ne fige pas tout. Le renouvellement reste possible. Le projet permet au registre d’autoriser une automatisation DNSSEC, par exemple un scanner CDSS ou CSYNC, à contourner l’approbation. La suppression du verrou demeure une procédure opérationnelle manuelle hors spécification.

Ces choix peuvent protéger la continuité : empêcher un renouvellement créerait un risque d’expiration, et l’automatisation DNSSEC peut éviter une rupture de chaîne. Mais l’étiquette « verrouillé » désigne alors un périmètre percé d’ouvertures nommées.

Le contournement doit garder l’identité du scanner, les observations, la politique invoquée et les états de délégation avant et après. La suppression manuelle doit produire un identifiant de cérémonie corrélable à l’historique EPP. Sinon, la voie la plus puissante devient la moins vérifiable.

Les services actuels montrent des cérémonies différentes

Le registre IANA des extensions EPP contient déjà une extension de verrouillage active de la Fondation suédoise de l’Internet, classée « Other » pour .se et .nu. Cette inscription ne correspond pas à l’adoption du nouveau projet individuel.

Internetstiftelsen explique que le registrar choisit comment vérifier le titulaire, déverrouille, effectue l’opération et reverrouille, immédiatement ou après une durée fixée par le registrar. DENIC décrit pour .de un autre circuit : un contact de verrou reçoit un jeton sur le mobile enregistré et un e-mail ; sans confirmation dans les sept jours calendaires, la demande est rejetée, et DENIC effectue son propre contrôle.

Ces services ne prouvent pas l’implémentation de la révision 00. Ils démontrent que le même nom commercial recouvre des règles d’enrôlement, de vérification, de délai et de retrait différentes. Une syntaxe commune rend ces écarts plus importants à déclarer, pas moins.

Conserver la cérémonie qui donne son sens au quorum

Je propose une trace de cérémonie pour chaque transformation en attente. Cette construction relève de la gouvernance éditoriale.

Elle fixe d’abord le domaine, le client authentifié, la session, les identifiants, l’heure, l’opération et une représentation canonique de l’état initial et de l’état demandé. Elle conserve la politique antérieure, son numéro de version, le délai, le nombre exigé et la liste de contacts.

Pour chaque approbateur, elle enregistre l’autorité représentée, l’ancienneté de l’enrôlement, la méthode et les domaines de contrôle nécessaires au test d’indépendance : employeur, fournisseur d’identité, espace de messagerie, administration de l’appareil ou du téléphone, émetteur du jeton et service de récupération. Des références contrôlées peuvent protéger les données sensibles.

Chaque défi reçoit un condensat lié à la modification exacte, un moment d’émission et d’expiration, une réponse, un résultat de validation et un état anti-rejeu. La décision finale nomme la règle d’indépendance appliquée, les accords retenus ou exclus et toute exception ou intervention manuelle. L’achèvement relie le tout au message de file et à l’état effectivement appliqué.

Le quorum répond alors à « combien ? ». La trace répond à la question décisive : ces accords représentaient-ils réellement les autorités indépendantes promises par le service ?

Sources