Résumé

  • La date limite de l’atelier de l’IAB sur le déploiement de l’authentification post-quantique est désormais fixée au 11 septembre 2026. L’atelier demande des mesures et des retours d’exploitation, non la sélection d’un algorithme.
  • Articles normalement publics, éléments retenus à la demande des auteurs, échanges non attribués, notes publiques avec exclusions et rapport IAB auront des portées différentes.
  • Une conclusion utile doit rester reliée au système testé, à sa version, aux résultats bruts, au document soumis, au régime de divulgation, puis à toute décision technique et à tout résultat en production.

Une date a changé, et les archives permettent de le voir. Le billet de l’IETF affiche maintenant le 11 septembre 2026. Le message du 4 septembre annonce une prolongation, tandis que l’appel initial de l’IAB et la fiche Datatracker conservent la date antérieure du 4 septembre.

Cette coexistence n’est pas une contradiction à effacer. Elle montre comment une décision acquiert sa provenance : l’ancien état documente le plan, le nouveau fixe l’échéance en vigueur. Les contributions de l’atelier auront besoin de la même discipline.

Le problème n’est plus seulement de définir un algorithme

FIPS 204 normalise ML-DSA et FIPS 205 normalise SLH-DSA. Ces textes définissent des mécanismes. Ils ne disent pas si une chaîne de certificats franchit une limite de protocole, si un HSM sait générer et répliquer la clé, si un micrologiciel dispose de la mémoire nécessaire ou si un magasin de confiance peut évoluer avant la fin de vie d’un parc.

L’atelier prévu à Prague les 11 et 12 octobre cherche précisément ce milieu manquant entre spécification et résultat. Il sollicite des documents courts sur des essais, des mesures, des coûts et des blocages : taille, temps, débit, mémoire, validation, certificats, jetons, signature logicielle ou matérielle, systèmes contraints et vérification hors ligne.

Les approches citées déplacent les contraintes au lieu de les abolir. Les signatures composites assemblent des composants et augmentent l’objet à gérer. Les Merkle Tree Certificates font dépendre la vérification d’un journal, de preuves et de leur fraîcheur. L’authentification par KEM modifie un échange interactif. Ce sont des travaux en cours, pas les choix de l’IAB.

La visibilité d’une contribution est une donnée de preuve

L’atelier est sur invitation et en présentiel. Une déclaration d’intérêt suffit pour se porter candidat, mais un papier pèse davantage sur l’ordre du jour ; le comité peut aussi inviter directement. Soumission, acceptation, invitation, présence et présentation ne sont donc pas synonymes.

Les papiers pertinents et acceptés seront normalement publiés. Un auteur peut demander la non-publication ou l’absence d’attribution de certains éléments. La règle de Chatham House peut s’appliquer à une discussion. Il n’y aura ni enregistrement public ni procès-verbal public ; des notes collaboratives doivent rester publiques hors passages protégés.

Cette architecture peut libérer une information qu’un opérateur réglementé ou un fournisseur ne publierait pas autrement. Mais elle impose de marquer la limite. Un papier public est vérifiable comme document, pas comme expérience reproduite. Un papier retenu peut éclairer la salle, pas être cité comme méthode inspectable. Une synthèse non attribuée ne permet pas de nommer une entreprise. Une note publique peut omettre volontairement le chemin qui a produit une conclusion.

Le futur rapport ne sera pas une norme

L’atelier prévoit un rapport de la filière IAB. RFC 4845 distingue la fidélité au déroulement de la responsabilité pour chaque affirmation technique : pour un atelier avec des participants extérieurs, l’approbation de l’IAB peut simplement attester que le rapport rend fidèlement compte des travaux et que le sujet mérite d’être conservé. Les publications IAB sont en général informatives.

RFC 8980, issu d’un atelier sur l’écart entre conception et réalité du déploiement, illustre une structure saine : papiers, échanges, conclusions et actions possibles demeurent identifiables. Il n’apporte aucune mesure actuelle sur l’authentification post-quantique.

Le risque apparaît quand la citation raccourcit la chaîne. « L’IAB a conclu » peut masquer quelques résultats publics, des réserves confidentielles et une synthèse éditoriale. « Blocage industriel » peut survivre à la version de micrologiciel qui l’avait créé. « Consensus » peut effacer la sélection des invités et les limites de divulgation.

La distinction proposée par Heng Lu dans Reality Layers est utile : une mesure, un papier, un atelier, un rapport, une spécification et un service opérationnel appartiennent à des couches différentes. La primauté du code exécuté ne nie pas l’utilité de l’institution ; elle exige seulement que l’institution ne parle pas à la place du résultat qu’elle n’a pas observé.

Un dossier minimal pour chaque résultat

Chaque contribution quantitative devrait nommer le composant, la version, le fournisseur cryptographique, l’algorithme et les paramètres. Elle devrait décrire l’objet signé, la charge, le matériel, le réseau, la référence de comparaison, la taille de l’échantillon, les unités et les catégories d’échec. Les données brutes doivent être liées, ou leur indisponibilité expliquée.

Le PDF soumis a ensuite besoin d’une date et d’une empreinte. Le régime de divulgation doit être explicite. Le rapport devra distinguer ce que disait le papier, ce que la salle a reformulé et ce qui repose sur un élément protégé. Une éventuelle suite dans un groupe de travail sera encore un autre acte. Enfin, seul un test local peut montrer qu’une version précise fonctionne dans le système concerné.

C’est une application de la Minimum Initial Specification : un registre commun mince pour rendre les preuves comparables, sans transférer à l’atelier la décision de déployer. La semaine supplémentaire augmente la possibilité de documenter. Elle n’allège pas la charge de preuve.

Sources

  1. Billet IETF et nouvelle échéance
  2. Annonce de prolongation
  3. Appel à contributions de l’IAB
  4. Fiche de l’atelier
  5. RFC 4845
  6. RFC 8980
  7. FIPS 204
  8. FIPS 205
  9. Signatures composites
  10. Merkle Tree Certificates
  11. Authentification par KEM
  12. Running-Code Primacy
  13. Minimum Initial Specification
  14. Reality Layers