Summary

  • Le projet individuel déposé le 23 octobre décrit des enregistrements DNS destinés à vérifier les clés et la révocation des profils d'origine de contenus numériques.
  • Un éditeur pourrait publier dans sa propre zone une liste des émetteurs de profil principal qu'il accepte. Une attestation provenant d'un autre émetteur serait refusée si cette liste est authentifiée.

Le badge est impeccable, le nom de l'organisme certificateur figure dessus. Mais qui l'a invité à parler au nom du journal ? C'est la question la plus intéressante du texte déposé par Shigeya Suzuki le 23 octobre. La fiche IETF le classe parmi les projets individuels actifs, sans adoption par une commission de normalisation. Sa destination annoncée est expérimentale.

Dans l'architecture proposée, un éditeur reçoit un profil principal, ou Core Profile, d'un émetteur. Le profil contient les clés publiques correspondant aux signatures de ses contenus. Des annotations, délivrées par d'autres organismes, ajoutent des attributs vérifiés. Signer un article ne suffit pas à établir qu'une clé reste valable aujourd'hui. Le projet place donc dans le DNS, sous _op, des empreintes de clés au format OPKEY. La présence ou l'absence authentifiée d'un enregistrement renseigne sur la validité du profil ; un enregistrement TXT sert à signaler la révocation d'une annotation. Les profils complets ne sont pas publiés dans le DNS.

La petite ligne qui change la répartition du pouvoir est un SVCB facultatif à _op.<originator>. Le propriétaire du domaine peut y nommer les émetteurs de profils principaux qu'il autorise. Si cette liste est validée par DNSSEC, le vérificateur compare l'émetteur du profil aux noms inscrits. Un émetteur admis dans l'écosystème général ne gagne donc pas automatiquement le droit de représenter cet éditeur précis. Le projet n'impose toutefois pas cette liste à tous : en son absence, lorsque le cas d'usage ne la rend pas obligatoire, l'éditeur reste sans restriction d'émetteur.

Le mécanisme exige de lire correctement le silence du DNS. Pour OPKEY, une réponse non signée, une preuve invalide ou une panne de résolution fait échouer la vérification ; elle ne prouve pas qu'un enregistrement manque. Pour le SVCB facultatif, une absence prouvée et sécurisée peut laisser l'éditeur sans liste, tandis qu'une réponse corrompue ou un délai dépassé doit arrêter la vérification. Les deux situations ne méritent pas le même tampon « absent ».

Reste le temps, ce rédacteur qui corrige après le bouclage. Le texte utilise une heure comme hypothèse pour la durée de vie des enregistrements et du cache négatif. Une ancienne réponse conservée en cache peut encore faire accepter une clé retirée jusqu'à l'expiration de sa durée de vie ; la validité de sa signature et les réponses périmées peuvent allonger la fenêtre. Dans un laboratoire réglé sur 60 secondes, une modification devenait visible par un résolveur validant en 63 secondes au plus. Ce chiffre décrit l'essai, pas un délai de retrait garanti sur Internet.