Résumé

  • La révision 02 crée un tableau de résultats provenant potentiellement de plusieurs émetteurs et rend obligatoires le schéma d’évaluation et l’URI de l’évaluateur.
  • Cette URI attribue le résultat ; elle n’atteste ni son origine, ni l’intégrité d’une republication, ni la valeur de la méthode employée.
  • Une décision sérieuse doit conserver ensemble le sujet, le schéma, l’émetteur, le serveur qui publie, la date, le statut et les éléments probants.

Dans une interface, un chiffre coloré finit vite par ressembler à un jugement. Le projet draft-bertoldi-regext-rdap-reliability-scoring-02, déposé le 6 septembre, tente justement d’empêcher cette confusion avant qu’un usage ne s’installe.

Le texte rebaptise reliabilityScoring en reliabilityAssessment, abandonne l’objet unique au profit du tableau reliabilityAssessment_results et exige, pour chaque entrée, scoreScheme et scoreIssuer. Il ajoute une échéance de validité, un identifiant utile en cas de contestation et trois états : actif, en cours d’examen et retiré. Les auteurs précisent qu’ils ne connaissent encore aucune mise en œuvre.

L’attribution n’est pas l’authenticité

La distinction la plus utile de cette nouvelle version tient en trois mots. L’identité répond à la question « à qui attribue-t-on ce résultat ? ». La confiance demande pourquoi le destinataire devrait se fier à cette partie. L’authenticité établit que l’assertion vient effectivement d’elle et n’a pas été altérée.

L’URI scoreIssuer ne remplit que la première fonction. Elle doit être stable, unique et, de préférence, sous le contrôle de l’émetteur. Elle n’est pourtant pas une signature. La confiance reste configurée hors protocole et l’assertion signée est renvoyée à une version future.

TLS ne transforme pas cette attribution en preuve. Selon le RFC 7481, HTTPS authentifie le serveur et protège l’échange. Il peut montrer quel point de terminaison a livré les octets reçus. Il ne démontre pas qu’un tiers cité dans ces octets en est l’auteur. Le même RFC sépare déjà l’intégrité du transport de l’exactitude des données ; la nouvelle proposition étend cette discipline aux appréciations.

Trois modes de publication, trois rapports de confiance

Le mode privilégié est un service RDAP exploité par l’évaluateur lui-même. Deux autres restent possibles : la republication par un registre, un bureau d’enregistrement ou un autre serveur, et l’auto-évaluation. Leur forme JSON peut être identique, pas leur force probante.

Dans le premier cas, le destinataire peut avoir configuré ensemble le serveur et l’émetteur. En cas de republication, il faut faire confiance à l’évaluateur et à l’intermédiaire, sans que la réponse distingue clairement leurs rôles. Dans l’auto-évaluation, l’identité peut être correcte alors que l’incitation à embellir le résultat est maximale.

Le projet refuse donc d’ajouter les évaluateurs au mécanisme d’amorçage du RFC 9224, réservé aux services faisant autorité pour les données d’enregistrement. Il écarte aussi un simple lien de renvoi depuis le serveur faisant autorité, car ce lien pourrait être pris pour une approbation. Trouver un serveur ne revient pas à légitimer son jugement.

Ce qu’une automatisation doit réellement conserver

La position d’une entrée dans le tableau n’indique ni priorité, ni autorité, ni fraîcheur. Une note de 7 n’a pas la même signification sous deux schémas différents. validUntil marque la fin de l’engagement de fraîcheur de l’émetteur, pas l’annulation rétroactive du résultat. Un statut absent ne signifie pas « actif ». Un résultat retiré peut rester publié afin qu’un client disposant d’une copie en cache voie le retrait. L’absence du membre ne prouve ni réussite, ni échec, ni absence d’évaluation.

L’objet de décision n’est donc pas le nombre seul. C’est l’ensemble formé par le sujet lié, le schéma, l’URI de l’émetteur, le serveur publiant, l’identifiant du résultat, la date, l’échéance, le statut et une trace des preuves.

Même le rattachement du sujet reste asymétrique. Le nom ldhName suffit pour un domaine. Pour un registrar, le service d’évaluation utilise un identifiant local, tandis que l’identifiant IANA n’apparaît dans publicIds qu’après la réponse. Le marquage du RFC 8521 est évoqué comme piste, non comme solution. Les registrars de ccTLD et ceux sans identifiant IANA restent un cas ouvert.

La procédure contradictoire demeure hors du protocole

Tout schéma destiné à la publication devrait désormais expliquer son modèle de menace, prévenir la partie évaluée, offrir une période de correction ou de contestation, minimiser les données et justifier spécifiquement la publication au niveau d’un domaine. C’est essentiel : un mauvais résultat peut servir de liste de reconnaissance à un attaquant.

Le texte ne choisit toutefois ni la durée, ni l’arbitre, ni la gouvernance, ni la sanction. C’est cohérent. Une enveloppe d’interopérabilité peut transporter l’état d’un différend ; elle ne reçoit pas, par sa syntaxe, le mandat de le trancher.

Cette franchise est la force de la révision. Le résultat reste informatif, ne vaut ni certification ni mécanisme d’exécution, peut devenir obsolète et peut pointer vers une preuve mutable ou indisponible. La bonne lecture n’est pas « le champ ne sert à rien », mais « le champ ne possède pas plus d’autorité que celle qu’il documente ».

Sources

  1. Fiche IETF Datatracker
  2. Projet RDAP, révision 02
  3. Projet RDAP, révision 01
  4. RFC 7480
  5. RFC 7481
  6. RFC 8521
  7. RFC 9082
  8. RFC 9083
  9. RFC 9224
  10. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  12. Running-Code Primacy