Résumé

  • clientTransferProhibited et serverTransferProhibited ont un effet impératif dans la RFC 5731 : le serveur doit refuser toute demande de transfert de l’objet domaine.
  • Leur préfixe situe le côté qui maîtrise le statut. Il ne fournit pas la décision humaine, le motif de politique, l’échéance ni la preuve que le compte capable de lever le verrou est protégé.
  • Une décision vérifiable exige deux pièces liées : un reçu de statut horodaté et un reçu distinct qui attribue le motif, l’autorité, la durée, la notification et la procédure de levée.

Le protocole sait dire non

Il faut commencer par reconnaître la force du verrou. La RFC 5731 ne présente pas les deux statuts d’interdiction comme de simples conseils. Tant que l’un d’eux appartient à l’état cohérent du domaine, les demandes de transfert doivent être rejetées. Le code apporte donc une information exploitable sur un verbe précis, à un instant donné.

Un écran de sécurité commet pourtant facilement un glissement. Il lit le code, puis affiche « protégé par le titulaire », « incident de sécurité » ou « verrou du registre ». Le premier constat vient du protocole ; les trois autres viennent d’une histoire que l’écran a ajoutée. Le statut ne contient pas sa propre cause.

La RFC permet qu’un texte lisible par une personne accompagne le statut pour en exposer la raison. Elle ne l’exige pas. Un objet conforme peut ne porter ni numéro de dossier, ni consentement, ni date d’expiration, ni trace d’une revue récente. Ce silence n’annule pas le verrou. Il oblige à chercher l’explication dans le système qui a pris la décision.

Cette sobriété est une qualité d’interopérabilité. Un prédicat étroit — refuser ce type de commande — se compare d’un serveur à l’autre. S’il devait aussi résumer un litige, une identité, un contrat et un calendrier, le même champ deviendrait vite impossible à interpréter sans connaître chaque institution.

Deux préfixes, plusieurs décisions possibles

Dans la grammaire de la RFC 5731, un statut commençant par client est ajouté ou retiré par le client sponsor, généralement le bureau d’enregistrement. Un statut server relève du serveur EPP, généralement le registre. Le client ne peut pas modifier un statut du serveur ; le serveur peut modifier ou supplanter un statut du client selon sa politique locale.

Cette distinction désigne une porte de contrôle, pas la personne qui l’a franchie. Un bureau d’enregistrement peut verrouiller par défaut à la création, agir à la demande du titulaire, appliquer une période imposée par une politique ou contenir un problème de compte. Côté registre, le même refus visible peut être lié à un différend, une période de rédemption, une demande du titulaire ou un service de verrouillage renforcé. Le code reste identique alors que les dossiers décisionnels ne le sont pas.

La documentation d’ICANN destinée aux titulaires traduit cette différence en parcours opérationnel. Les codes client sont placés par les bureaux d’enregistrement, les codes serveur par les registres. Pour le premier, le titulaire demande normalement la levée au bureau d’enregistrement. Pour le second, celui-ci doit parfois travailler avec le registre, ce qui peut allonger le délai. Cette indication aide à trouver l’interlocuteur ; elle ne révèle toujours pas le motif du cas particulier.

La politique porte la partie explicative

Dans son champ d’application, la politique de transfert d’ICANN décrit ce que la cartographie EPP n’a pas vocation à trancher. Elle attribue l’autorité du titulaire, encadre la demande du bureau gagnant, énumère des motifs de refus et impose, dans les situations prévues, de communiquer la raison au titulaire et au bureau potentiel.

Ces motifs ne forment pas une seule catégorie « risque ». Une preuve de fraude n’est pas un doute raisonnable sur l’identité. Une dette répondant aux conditions de la politique n’est pas l’opposition expresse du titulaire. Une décision judiciaire, une procédure de litige, les délais suivant un enregistrement ou un transfert et le verrou de soixante jours après changement de titulaire ont chacun leur autorité et leur horloge.

La politique refuse aussi de faire du simple statut « Registrar Lock » une justification autonome lorsque le titulaire n’a pas reçu une possibilité raisonnable de déverrouiller avant la demande. Lorsqu’une opposition générale émane du titulaire, son consentement exprès et éclairé ainsi qu’un moyen accessible de lever le verrou comptent. Le statut applique le résultat présent ; le dossier de politique explique pourquoi ce résultat est légitime et quand il doit cesser.

Il faut donc conserver deux reçus. Le premier nomme le domaine, la valeur exacte, la source interrogée, l’heure d’observation et l’état ultérieur. Le second nomme la règle ou le contrat, la partie qui a demandé ou imposé la restriction, l’autorisation, la date d’effet, le déclencheur de revue ou d’expiration, l’avis envoyé et la voie de levée.

Trois horloges derrière un seul badge

L’état d’un domaine évolue sur plusieurs temps. L’horloge du serveur date l’application du statut dans l’état EPP faisant autorité. L’horloge de la politique date la naissance et l’échéance du motif. L’horloge d’observation indique quand RDAP, Whois, le portail du bureau ou un prestataire de surveillance a récupéré puis présenté l’information.

Un cache peut retarder la vue publique. Une interface peut conserver son libellé après une opération. Un dossier peut arriver à échéance avant que sa projection technique soit retirée ; inversement, le serveur peut être déverrouillé avant le rafraîchissement d’un agrégateur. Une capture d’écran prouve seulement ce que cette interface montrait à cette heure. Elle ne prouve pas automatiquement l’état actuel du serveur, son auteur ou son motif.

La RFC 5731 fournit un test de cohérence particulièrement utile : pendingTransfer ne peut coexister ni avec clientTransferProhibited, ni avec serverTransferProhibited. Le premier signifie qu’une action de transfert a été traitée mais n’est pas terminée ; les seconds imposent de rejeter la demande. Si une base affiche les deux, il faut d’abord vérifier les dates, les caches, le mélange de sources et la couche de présentation. La contradiction signale une dette de données, pas encore une fraude ni une non-conformité du registre.

Un transfert verrouillé n’est pas un domaine entièrement verrouillé

Le langage ordinaire suggère qu’un « verrou » ferme tout. EPP distingue justement les verbes. Le transfert, la mise à jour, la suppression et le renouvellement disposent de prohibitions séparées. Les statuts hold concernent la publication de la délégation DNS. Empêcher un transfert ne démontre donc pas que les contacts ne peuvent pas être modifiés, que le domaine ne peut pas être supprimé ou que l’accès au compte est sain.

Un attaquant ayant pris le compte du bureau d’enregistrement peut chercher à retirer un statut client. À l’inverse, une offre commerciale de verrouillage au registre peut imposer un appel hors bande, deux approbateurs, un identifiant indépendant ou un délai obligatoire. Ces contrôles méritent d’être reconnus lorsqu’ils sont attestés par le contrat et le fonctionnement réel ; ils ne sont pas inclus par magie dans le seul token EPP.

Les conseils de sécurité d’ICANN décrivent d’ailleurs le verrou de transfert comme une couche utile, non comme une protection infaillible. Ils traitent séparément la confidentialité du compte et l’authentification en plusieurs étapes. Une vue honnête garde donc des reçus distincts pour l’accès au compte, les changements de privilèges, l’information d’autorisation, les statuts de mise à jour ou suppression, la délégation DNS et les contacts de récupération.

Attribuer l’auteur sans lui attribuer l’exploitation

Scott Hollenbeck est l’auteur nommé des RFC 5730 et 5731. Son profil IETF indique une participation active depuis le milieu des années 1990, plusieurs présidences de groupes de travail et un mandat de directeur du domaine Applications entre 2004 et 2006. La page lui associe actuellement 39 RFC.

Ces éléments établissent une contribution majeure à la normalisation. Ils ne font pas de Hollenbeck l’opérateur d’un registre, le décideur d’un refus donné ou le détenteur d’un domaine. Son nom appartient à la provenance de la spécification. Le bureau ou le registre appartient à la provenance du changement d’état. Respecter ces limites est la même discipline dans les deux cas.

Reconstituer le dossier sans exposer les secrets

Le dossier minimal joint l’état exact, sa source, son heure et l’événement qui le remplace aux identifiants de transaction ou de requête disponibles. Il relie ensuite la politique applicable, sa version, le demandeur, le rôle responsable, la preuve d’autorité, la durée, les notifications et la procédure de levée. Si un transfert a été tenté, un troisième reçu conserve la demande, le traitement de l’autorisation, la réponse du serveur, la raison communiquée et l’issue finale.

Il n'est pas nécessaire de publier les secrets, les justificatifs d’identité ou des données personnelles superflues. Il est nécessaire de conserver assez de provenance pour qu’un auditeur autorisé distingue un verrou demandé par le titulaire, une mesure de politique, un litige, une erreur et une action hostile.

Le meilleur contre-argument doit rester au centre : le statut est une vraie protection. Dans un état conforme, il bloque la commande de transfert. Un verrou par défaut ou un service de registre bien exploité ajoute une friction précieuse contre le détournement. L’erreur n’est pas de croire le protocole ; c’est de lui demander d’attester la décision qu’il ne transporte pas.

La cartographie de Hollenbeck donne une phrase courte et ferme : cette commande doit être refusée. L’institution qui applique la restriction doit écrire la suite : qui, pourquoi, jusqu’à quand et selon quelle procédure de retour. Le verrou arrête le transfert ; seule une preuve attribuable l’explique.

Sources