Résumé

  • Le projet individuel Wathīqa, publié dans une première révision, décrit une chaîne d’attestations renouvelables sous de nouveaux algorithmes de signature.
  • Un reçu d’inclusion dans un journal de transparence doit fournir une preuve authentifiée « au plus tard » ; l’ancre issue d’une balise aléatoire porte une indication « au plus tôt » que la révision 00 qualifie elle-même de non authentifiée.
  • Le contrôle du reçu de témoin n’est obligatoire que si l’appelant fournit l’ensemble W de clés de confiance. Sans W, la chaîne peut satisfaire les contrôles cryptographiques sans preuve temporelle de témoin.
  • Le texte vise le statut Experimental mais reste un Internet-Draft individuel, sans adoption par un groupe de travail ni aval de l’IETF. Son argument de sécurité n’a pas fait l’objet d’un examen cryptographique indépendant.
  • Le bon résultat opérationnel n’est donc pas un voyant unique : validité de la chaîne, borne supérieure attestée, borne inférieure non vérifiée et décision de politique doivent être rendues séparément.

Le renouvellement doit précéder la rupture

Une archive cryptographique est une promesse faite au futur. Aujourd’hui, une clé et un algorithme permettent de vérifier une signature. Demain, une faiblesse publique, un progrès de cryptanalyse ou la compromission d’une autorité d’horodatage peut modifier la valeur probante de la même suite d’octets. Ajouter une nouvelle signature après ce basculement ne démontre pas que l’ancienne était encore fiable la veille.

C’est pourquoi le RFC 4998 demande le renouvellement des horodatages d’archive avant l’affaiblissement des algorithmes concernés ou l’invalidité des certificats. Le RFC ne prétend pas déduire ce calendrier du format lui-même : les informations sur la robustesse, les compromissions possibles et les durées acceptables sont extérieures à la syntaxe.

Le projet Wathīqa transpose ce problème à une chaîne dite agile. Le contenu reçoit une adresse cryptographique. Une première entrée la signe ; chaque entrée suivante la signe avec une primitive déclarée et s’engage sur le hachage canonique de l’entrée précédente. ML-DSA et SLH-DSA renvoient respectivement aux normes FIPS 204 et FIPS 205. La normalisation de ces primitives ne valide ni le profil, ni son exploitation, ni la date à laquelle une politique locale devra les remplacer.

Une fenêtre temporelle dont un côté reste déclaratif

Le texte veut encadrer chaque maillon par deux informations. Côté supérieur, un témoin de journal de transparence fournit une tête d’arbre signée et un chemin d’inclusion. Si la clé du journal est approuvée et si la preuve est correcte, on peut établir que la signature du maillon figurait dans l’arbre au plus tard à la date de cette tête. Le mécanisme reprend les notions d’arbre de Merkle du RFC 6962.

Côté inférieur, une impulsion de balise aléatoire est censée fournir un élément qui n’était pas disponible avant sa publication. La page de la NIST Randomness Beacon 2.0 décrit des impulsions numérotées, horodatées, signées et liées par hachage. Elle présente toujours le service comme une version bêta en chantier.

Or la révision 00 de Wathīqa ne vérifie pas la preuve de cette impulsion. Elle incorpore dans le maillon des métadonnées de balise et contrôle que l’enregistrement d’ancre reste lié à la signature. Ce contrôle d’intégrité interne ne démontre pas que la NIST a réellement produit l’impulsion annoncée. Le chapitre de sécurité le dit sans détour : un adversaire peut inscrire des métadonnées « au plus tôt » arbitraires, et cette ancre ne doit pas être utilisée comme temps authentifié.

Il est important de conserver le choix exact des mots. Le champ n’est pas inutile : il prépare une future vérification et empêche qu’une ancre soit détachée de son maillon sans laisser de trace. Mais, dans l’état actuel, il porte une déclaration. Le représenter comme une borne validée transformerait une donnée structurée en autorité qu’elle ne possède pas.

La présence ou l’absence de W change la preuve

L’autre côté de la fenêtre dépend lui aussi d’un paramètre que l’interface risque de cacher. La procédure reçoit facultativement W, un ensemble de clés publiques de témoins jugés fiables. Avec W, chaque maillon doit comporter un reçu d’inclusion valide, la tête d’arbre doit être signée par une clé autorisée et les dates doivent rester monotones. Sans W, ces obligations ne s’appliquent pas. Le vérificateur recalcule toujours l’adresse du contenu, contrôle les signatures et suit les hachages des prédécesseurs, puis peut accepter la chaîne sur cette base plus étroite.

Deux appels conformes sur le même fichier peuvent donc répondre positivement à des questions différentes. Le premier signifie : « la structure et les signatures sont valides ». Le second ajoute : « les reçus ont été vérifiés sous telle liste de témoins ». Si un produit réduit les deux réponses à « preuve valide », il efface précisément l’hypothèse dont dépend la chronologie.

La liste de confiance n’est pas un détail fixe. Les clés tournent, des opérateurs disparaissent, des juridictions changent et des journaux peuvent présenter des vues incohérentes. Le projet recommande une succession de clés de témoins, autorisée par quorum et ancrée dans un registre append-only. Cette orientation signale le problème, mais ne définit pas encore l’organisation qui convoque le quorum, traite une compromission, arbitre une branche concurrente ou maintient l’ancre pendant un siècle.

Un premier texte qui doit encore rejoindre son code

Le Datatracker classe le document comme Internet-Draft individuel, sans flux RFC. Daté du 3 septembre 2026 et annoncé publiquement le 5 septembre dans l’archive I-D, il vise le statut Experimental et expire le 7 mars 2027. Ces informations décrivent une proposition active, pas une décision de l’IETF.

Le texte affirme qu’une implémentation Python complète existe et que des vérificateurs JavaScript et Rust reproduisent le hachage canonique à l’aide de vecteurs partagés. Il précise en même temps que l’argument de sécurité n’a pas reçu de revue cryptographique indépendante. Aucun lien de dépôt ni identifiant de commit n’apparaît dans la révision 00 ; cette enquête n’a donc pas pu reproduire les résultats annoncés.

Une couture de version mérite également d’être réparée. La section 4.3 présente l’enveloppe ASN.1 DER comme le profil de version 3 et renvoie le module détaillé vers un fichier Python externe, annoncé comme « faisant autorité » en attendant son intégration. L’annexe B parle, elle, d’un profil DER version 4, dont les versions 1 à 3 restent lisibles tandis que seule la version 4 serait émise. Les modules ERS modernisés du RFC 9169 offrent une base ASN.1 publiée, mais ne permettent pas de choisir entre ces deux indications propres à Wathīqa.

Cette contradiction peut être une simple trace de révision. Elle n’établit ni une faille, ni l’échec d’un logiciel. Elle interdit seulement de traiter la description actuelle comme une version reproductible et autonome. Les deux types de média envisagés sont eux aussi indiqués comme encore non déposés. Code, vecteurs, format et identifiants doivent être gelés ensemble avant qu’une démonstration d’interopérabilité ait un objet stable.

Ce que la chaîne démontre — et ce qu’elle laisse décider

Le noyau du profil reste compréhensible. Une partie indépendante peut recalculer l’adresse du contenu, vérifier chaque signature et confirmer que les maillons s’engagent bien sur leurs prédécesseurs. Avec une politique de témoins explicite, elle peut ajouter une preuve « au plus tard ». Elle ne peut pas encore authentifier le côté « au plus tôt » à partir du chemin décrit dans la révision 00.

La chaîne ne sait pas non plus décider quand un algorithme est devenu insuffisant, quelle autorité de veille un organisme suit, quels témoins il accepte ou quel incident impose un renouvellement d’urgence. Ce sont des décisions locales légitimes. Elles deviennent dangereuses uniquement lorsque l’interface les transforme en propriétés intrinsèques du fichier.

La proposition mérite donc d’être lue comme une séparation encore inachevée : un commun technique réduit aux preuves reproductibles, puis une politique de confiance détenue par l’utilisateur du document. Le système gagnera en crédibilité s’il nomme la partie absente, au lieu de laisser un résultat binaire l’absorber.