Résumé

  • RFC 3982 distinguait deux absences : private désignait une donnée susceptible de ne jamais être publiée, tandis que denied signalait un refus lié au niveau d’accès présent.
  • Une valeur communiquée pouvait porter specialAccess et doNotRedistribute; le protocole séparait ainsi l’accès privilégié de l’autorisation de redistribution, sans prétendre imposer techniquement la règle.

Une analyste chargée d’un abus reçoit le nom d’un contact de domaine. Son compte est authentifié, le serveur a accepté la requête et la valeur apparaît. Rien de cela ne répond encore à la question suivante : peut-elle coller ce nom dans un ticket partagé avec vingt prestataires ? RFC 3982 prévoyait précisément que la réponse puisse voyager avec la valeur.

La notice RFC Editor, la page des errata et l’historique Datatracker situent cette norme de janvier 2005. Elle définissait le type de registre de domaines d’IRIS : requêtes et résultats structurés pour domaines, hôtes, contacts, registraires et autorités d’enregistrement. Son apport ne se réduisait pas à remplacer des lignes de texte par du XML. Le schéma conservait la politique au niveau de chaque valeur.

Le cahier des charges existait déjà. RFC 3707, avec sa notice, ses errata et son dossier IETF, exigeait qu’un protocole de registres puisse exprimer trois situations quand une valeur n’était pas livrée : l’omission sans explication, l’insuffisance d’autorisation et une contrainte de confidentialité indépendante du niveau d’autorisation. Lorsqu’une valeur était fournie, le protocole devait pouvoir la marquer « ne pas redistribuer » et « accès spécial accordé », y compris simultanément.

Cette exigence partait d’une faiblesse documentée de WHOIS. RFC 3912, sa notice, ses errata et son historique décrivent une requête textuelle sur le port TCP 43, suivie d’une réponse textuelle. La norme reconnaît l’absence de sécurité forte, de contrôle d’accès, d’intégrité et de confidentialité. Un opérateur pouvait ajouter des avertissements lisibles par une personne, mais aucun vocabulaire commun ne garantissait qu’un logiciel conserverait le motif d’une absence ou la condition d’une divulgation.

Dans RFC 3982, un élément pertinent pouvait être présent sans contenu. Dans ce cas, il devait porter au moins l’un de deux attributs booléens. private indiquait que le contenu était absent parce qu’il pouvait ne jamais être publié. denied indiquait que la politique interdisait sa communication au niveau d’accès actuel. Deux cellules vides pouvaient donc appeler des décisions opposées : ne pas insister dans le premier cas, demander une habilitation adaptée dans le second.

Le texte ne disait pas que toute personne authentifiée recevrait la donnée refusée. Il ne disait pas non plus qu’un champ privé était absent de la base. Il décrivait la raison communiquée par le serveur. L’omission complète demeurait possible et ne donnait aucune explication standardisée.

Lorsque le contenu était présent, deux autres attributs devenaient possibles. specialAccess signalait que la valeur avait été remise grâce à des droits particuliers. doNotRedistribute demandait qu’elle ne soit pas retransmise. Le premier qualifiait l’origine de l’accès; le second, le comportement attendu après réception. Une même valeur pouvait porter les deux. C’est une architecture plus précise qu’un simple indicateur « privé/public ».

Cette précision se perd facilement. Un adaptateur transforme le XML en table, conserve la chaîne de caractères et supprime les attributs. Une interface affiche le contact sans afficher la restriction. Une copie vers un entrepôt général transforme un résultat exceptionnel en donnée ordinaire. Le système paraît avoir préservé l’information alors qu’il a supprimé la partie qui réglait son usage.

Les étiquettes n’étaient toutefois ni chiffrement ni police automatique. RFC 3981 et sa notice plaçaient les erreurs d’autorisation et le contrôle préalable des permissions dans le cœur IRIS, tout en laissant l’authentification et la confidentialité au transport applicatif. RFC 3983 et sa notice définissaient la correspondance BEEP. RFC 3982 n’ajoutait pas de précaution de sécurité au-delà de ce cadre. Une étiquette pouvait rendre une obligation lisible par machine; elle ne pouvait empêcher physiquement une copie ni créer, à elle seule, une sanction juridique.

La question a réapparu avec RDAP. RFC 9083, sa notice, ses errata et son historique Datatracker définissent le modèle de réponse JSON. RFC 9537, avec sa notice, ses errata et son dossier IETF, ajoute une extension de caviardage explicite.

RFC 9537 part du constat qu’un champ peut manquer faute de donnée ou faute de privilège. Il distingue suppression, valeur vide, valeur partielle et remplacement, peut nommer le champ concerné et indiquer une raison. Il refuse les substituts génériques du type XXXX, jugés incohérents et peu fiables. Il avertit aussi qu’un signal de caviardage révèle parfois l’existence même d’une donnée sensible.

Les sources ne prouvent pas une filiation directe entre IRIS et cette extension RDAP; il ne faut pas l’inventer. Elles montrent plutôt la persistance d’un même problème. Une absence sans provenance devient une conclusion abusive. Une valeur sans condition d’usage devient une permission trop large. RFC 3982 avait placé ces différences dans le protocole, là où les machines pouvaient les préserver — ou les perdre.

Sources