Résumé

  • Le RFC 5105 dit qu’une signature valide est nécessaire, mais insuffisante, pour qu’un jeton de validation soit valable. Le registre doit encore contrôler l’élément signé, l’algorithme, la clé de l’entité accréditée, le registrar, le numéro, la méthode, les dates et le risque de rejeu.
  • Le jeton relate une validation effectuée. Il ne constitue ni la décision du registre, ni le résultat EPP, ni la publication DNS faisant autorité, ni la preuve qu’un service a fonctionné.

Un jeton a été produit lundi. Sa signature est encore mathématiquement correcte vendredi. Entre-temps, le registre a retiré l’accréditation de l’entité de validation et modifié la durée pendant laquelle une validation peut servir à une demande. Quelle date doit gouverner la décision ?

La réponse n’est pas cachée dans la valeur de signature. Elle dépend de l’instant de la demande, de la version de politique, de l’état de confiance et de la portée exacte du jeton.

Le RFC 5105 définit un document XML signé destiné au monde ENUM. Un nom ENUM dérive d’un numéro E.164 ; l’inscription doit donc rester liée au titulaire réel du numéro. Une Validation Entity, ou VE, vérifie la relation. Un Registrar porte ensuite la demande au Registry. Ces fonctions ne fusionnent pas parce qu’elles manipulent le même fichier.

Le RFC 4725 rend cette séparation institutionnelle explicite. Il distingue l’Assignee du numéro, le Registrant du domaine ENUM, la VE, le Registrar, le Registry, le prestataire DNS et le fournisseur de l’application. La VE constate. Le Registrar transmet. Le Registry décide et tient la base maîtresse des délégations. Les serveurs autoritatifs publient. L’application exploite éventuellement le résultat.

Le jeton sert à transporter le constat de la VE sur une liaison où le Registrar ne possède pas nécessairement l’autorité permettant d’affirmer le droit d’usage. C’est précisément pourquoi la provenance et l’intégrité comptent. La signature empêche un intermédiaire de réécrire silencieusement le numéro, la méthode ou le demandeur.

Le noyau obligatoire contient un numéro de série propre à la VE, un numéro E.164, éventuellement le dernier numéro d’un bloc de même longueur, l’identifiant de la VE, celui du Registrar, celui de la méthode, la date d’exécution et, facultativement, une date d’expiration. Une section distincte peut ajouter des coordonnées. Aucun de ces champs ne transforme le document en ordre adressé au Registry.

La chronologie mérite une attention particulière. La date d’exécution décrit le moment de la validation. La date d’expiration décrit la fin déclarée de cette validation. Son absence signifie une validité infinie dans le format. Mais le même RFC impose au Registry de vérifier si cette absence est admise par sa politique. Il impose aussi à la politique locale de fixer combien de temps après l’exécution le jeton peut autoriser une délégation afin de limiter le rejeu.

Ainsi, « non expiré » ne veut pas dire « autorisé ». Un jeton peut annoncer une expiration future et arriver après la fenêtre de présentation. Il peut omettre l’expiration alors que le Registry interdit les durées illimitées. Il peut être ponctuel mais concerner un autre Registrar. La signature ne tranche aucune de ces comparaisons.

Le certificat inclus ne tranche pas davantage l’accréditation. Le RFC laisse au Registry plusieurs modèles : agir lui-même comme autorité de certification, accepter une autorité publique ou n’accepter que des clés préenregistrées. Le certificat fournit une chaîne possible. Il ne choisit pas la racine de confiance et ne prouve pas que son sujet possède aujourd’hui le statut de VE accréditée.

Une piste d’audit doit donc conserver l’instant et la version de l’accréditation. Un certificat peut rester valide au sens X.509 après la fin d’un accord institutionnel. À l’inverse, une politique future ne doit pas effacer le fait qu’une clé était acceptée lors d’une décision ancienne. L’état historique et l’acceptabilité actuelle sont deux questions.

Le RFC utilise XML-DSIG en mode enveloppé avec canonicalisation XML exclusive. Ce choix stabilise les octets à signer lorsque le jeton est placé dans un protocole XML plus large. Des déclarations d’espace de noms héritées ne doivent pas invalider la signature. Cette normalisation est utile, mais elle n’accorde aucune autorité métier.

La portée signée est plus décisive encore. Reference URI="#TOKEN" doit viser l’élément portant Id="TOKEN". Le texte avertit que déplacer cet identifiant vers la section facultative tokendata rendrait la signature sans valeur pour l’objectif prévu. Un moteur générique pourrait valider la cryptographie sur ce petit sous-arbre ; il n’aurait pas couvert le numéro, la méthode et les dates dont le Registry a besoin.

C’est la différence entre une preuve correcte et une question correctement posée. Le moteur cryptographique peut répondre fidèlement que la clé a signé l’élément référencé. Le Registry doit encore vérifier que cet élément est bien le jeton complet, que les transformations sont approuvées, que l’algorithme est autorisé et que la clé appartient à une VE accréditée.

Le RFC formule lui-même la limite : une signature valide est une condition nécessaire, mais non suffisante, d’un jeton valide. Il cite le certificat et le schéma XML comme contrôles supplémentaires. Cette phrase interdit de faire d’un voyant vert de bibliothèque la décision finale.

L’identifiant du Registrar matérialise une autre frontière. Le Registry doit comparer les informations du jeton avec la demande réelle. Si un second Registrar intercepte un jeton signé pour le premier, la signature reste valide. Pourtant, la demande du second doit échouer. Ici, l’intégrité parfaite produit précisément la preuve d’une discordance.

La portée E.164 impose le même soin. Le premier numéro et l’éventuel dernier numéro définissent un intervalle fermé ; ils doivent avoir la même longueur. Une normalisation qui élargit cet intervalle ou perd sa structure change ce que la VE a affirmé. Le Registry, et non la signature, compare cette portée au nom ENUM demandé.

Le numéro de série n’est unique que pour une VE. Stocker le numéro seul détruit son espace de noms. Même le couple VE-série ne suffit pas à autoriser : il faut le hash du jeton, le Registrar, la portée, la méthode, les dates, la fenêtre de politique et le résultat antérieur. C’est cet ensemble qui permet de repérer un rejeu plutôt que de supposer qu’un compteur est universel.

La méthode de validation demeure locale. Son identifiant indique la procédure annoncée ; il ne démontre pas qu’elle a été exécutée correctement ou qu’elle reste admissible. Une méthode peut convenir à une catégorie de numéros et pas à une autre. Une règle peut changer. Le registre doit dater l’évaluation au lieu de laisser le libellé parler à la place de la politique.

Le cycle de vie continue après l’inscription. Le RFC 4725 exige que la délégation ENUM suive la situation du numéro E.164. Une revalidation réussie peut permettre la continuité. Une revalidation échouée doit mener à une suspension, immédiatement ou à l’expiration selon le mécanisme et l’éventuel délai de grâce. Le jeton initial ne devient pas une autorisation perpétuelle parce que sa signature peut encore être recalculée.

La confidentialité reste une couche différente. Le contenu du jeton n’est pas chiffré. Les coordonnées facultatives peuvent donc être lisibles sur le chemin, sauf mécanisme supplémentaire. Chiffrer le transport ne change pas la portée de la signature ; signer le contenu ne le rend pas secret. Une preuve d’identité technique ne doit pas servir de déclaration implicite sur la protection des données.

Les algorithmes ont aussi une histoire. Le RFC exigeait la prise en charge de RSA-SHA1 et RSA-SHA256 tout en signalant déjà les doutes portant sur SHA-1. Il confiait au Registry le choix des algorithmes et tailles de clé acceptés. Reconnaître un URI d’algorithme, savoir l’exécuter et l’accepter aujourd’hui sont trois faits distincts.

Une fois le jeton accepté, la délégation n’est toujours pas une réalité observée partout. Le RFC 5076 décrit une extension EPP permettant d’ajouter, modifier, retirer ou consulter des informations de validation. Un résultat EPP réussi prouve quelque chose sur cette transaction. Il ne prouve pas à lui seul la publication dans la zone autoritative.

Le Registry peut avoir accepté la demande tandis qu’un générateur de zone échoue. Les serveurs autoritatifs peuvent publier alors qu’un résolveur voit encore un cache ancien. Le résolveur peut obtenir un NAPTR alors que l’URI est erroné ou inaccessible. L’application peut joindre une destination sans accomplir la communication prévue. Aucune de ces étapes n’est signée rétroactivement par la VE.

Le RFC 3761 encadre la recherche ENUM qui vient en aval. Le jeton concerne l’éligibilité de la délégation. Il n’est ni une preuve DNSSEC, ni une photographie de zone, ni un test de résolution ou de service.

Une architecture vérifiable conserve donc plusieurs reçus. D’abord les octets exacts du jeton, son hash, le schéma, l’élément référencé, les transformations, la canonicalisation, les algorithmes, la chaîne de certificat et les ancres de confiance. Ensuite, l’identité et l’accréditation de la VE, la série, le Registrar, la méthode, la portée E.164, les dates et la politique applicable.

Puis viennent les décisions : comparaison avec la demande, contrôle du rejeu, acceptation ou refus motivé du Registry, transaction EPP, état de la délégation, publication autoritative, observation par un résolveur et résultat de l’application. Chaque reçu garde son horloge et sa provenance. Une couche peut citer la précédente ; elle ne doit pas se l’approprier.

Cette discipline rejoint les couches de réalité de Heng Lu. Une signature est une réalité forte de représentation et de provenance. Elle perd sa valeur lorsqu’on la fait parler à la place d’une décision locale ou d’un système en fonctionnement. Le code exécuté doit rendre visibles ses propres transitions.

La question de direction est donc simple : que publie le service cryptographique ? S’il publie authorized=true, il s’arroge une autorité qu’il ne possède pas. Il devrait publier l’objet couvert, la clé, l’algorithme, le résultat, la politique cryptographique et les contrôles encore ouverts. Le Registry peut alors produire, sous sa propre responsabilité, la décision de délégation.

Sources