Résumé

  • L’IAB prépare à Prague, les 11 et 12 octobre, un atelier sur l’expérience réelle, les obstacles et les questions ouvertes du déploiement de l’authentification post-quantique.
  • L’appel à contributions fixe une limite nette : la rencontre n’a pas vocation à comparer, recommander ou faire converger des solutions, à choisir des algorithmes, à les normaliser, ni à diriger les groupes de l’IETF ou de l’IRTF.
  • Le corpus restera néanmoins sélectionné par le poids accordé aux articles, les invitations, les décisions d’accès et les choix de confidentialité. Ces outils sont légitimes, mais leur effet doit rester visible.
  • Un registre reliant preuves et affirmations permettrait de distinguer expérience d’un participant, synthèse des organisateurs, avis de l’IAB et éventuels travaux ultérieurs de l’IETF.

Le pouvoir le plus utile est celui auquel la réunion renonce

L’appel publié le 21 août par l’Internet Architecture Board attire d’abord l’attention par son sujet. Pourtant, sa disposition de gouvernance la plus importante est négative : elle énumère ce que la réunion ne décidera pas.

L’IAB veut réunir à Prague des responsables de mise en œuvre, des opérateurs et des concepteurs de protocoles. Les 11 et 12 octobre 2026, ils doivent documenter les difficultés concrètes de l’authentification post-quantique, alors que l’établissement de clés post-quantique est déjà plus avancé. Certificats, jetons d’identité, modules matériels, éléments sécurisés et signature de logiciels ou de micrologiciels font partie du terrain.

L’atelier ne doit cependant ni comparer les approches pour désigner la meilleure, ni en recommander une, ni organiser une convergence. Il ne choisira et ne normalisera aucun algorithme. Cette abstention protège la valeur de l’enquête : on peut mettre en commun des contraintes avant qu’une enceinte de normalisation décide quel problème relève de sa compétence.

Le futur rapport sera publié dans l’IAB Stream. L’appel précise parallèlement que la rencontre n’est pas destinée à donner des instructions aux groupes de travail de l’IETF ou aux groupes de recherche de l’IRTF. Les organisateurs pourront suggérer un lieu de suivi. Le rapport peut donc nourrir une étape suivante ; il n’en tient pas lieu.

Au 31 août, rien ne permet encore d’évaluer un résultat. Les textes de position sont attendus le 4 septembre. Les invitations partent progressivement et toutes les réponses doivent être données avant le 14 septembre. Il n’existe encore ni liste définitive des participants, ni ordre du jour, ni notes, ni rapport. L’actualité porte sur l’architecture annoncée de l’enquête.

Une sélection nécessaire n’est pas un échantillon représentatif

La participation se fera sur invitation et, en principe, en personne. Une présence à distance pourra être autorisée à la discrétion du comité de programme. Celui-ci demande de préférence un document d’une ou deux pages décrivant une expérience de déploiement. Une simple déclaration d’intérêt est recevable, mais un document pèsera davantage sur l’ordre du jour.

Déposer un texte ne donne pas droit à une présentation. Les contributions servent à composer les séances ; toutes ne seront pas exposées. Le comité peut également inviter une personne jugée essentielle sans lui demander de document. Enfin, un auteur qui ne vient pas peut tout de même contribuer, et un texte pertinent peut être publié.

Une petite rencontre spécialisée a besoin de choix. Un exploitant qui possède l’information décisive peut ne pas avoir vu l’appel, ne pas pouvoir voyager ou ne pas disposer du temps nécessaire pour rédiger. L’invitation directe n’est donc pas, en soi, un défaut. Elle produit toutefois un corpus construit, non un recensement de tous les déploiements.

Le rapport gagnerait à publier le périmètre de cette construction : nombres de documents, déclarations d’intérêt, invitations directes, participants acceptés, contributions sans présence, accès à distance et retraits. Il pourrait indiquer les secteurs et contextes techniques recherchés, ainsi que les angles restés peu couverts, sans classer les individus ni dévoiler les candidatures.

Ce reçu ne transformerait pas la salle en représentation de l’Internet. Il permettrait simplement au lecteur de savoir sur quel type d’échantillon reposent les observations.

Une preuve publique n’a pas le même statut qu’une confidence protégée

Les documents acceptés ont vocation à devenir publics. Un auteur peut néanmoins demander le retrait de son texte ou l’utilisation de certaines informations sans attribution. Une discussion peut relever de la règle de Chatham House. Aucun enregistrement ou procès-verbal public n’est prévu. Des notes collaboratives doivent servir de référence publique pour la rédaction, sauf pour les passages ainsi protégés.

Cette souplesse peut améliorer le fond. Un opérateur ne décrira peut-être une limite matérielle, un échec de migration de certificats ou une contrainte d’achat que si le produit, le client ou l’incident demeure non identifiable. Une transparence nominale absolue favoriserait les faits faciles à communiquer plutôt que les faits difficiles à comprendre.

Mais la confidentialité modifie la capacité de vérification. Un texte public peut être lu et cité. Une information non attribuée peut étayer une observation, sans offrir la même provenance. Une discussion protégée peut révéler un motif réel tout en empêchant le public d’en tester la portée. Les notes, quoique publiques, resteront volontairement incomplètes.

Il ne faut pas exclure ces matériaux. Il faut conserver leur état. Une conclusion soutenue par trois études publiques de déploiement n’est pas équivalente à une affirmation issue d’une seule intervention protégée. Les deux peuvent être utiles, mais elles ne doivent pas recevoir la même apparence documentaire.

Un registre de provenance jusqu’à l’affirmation finale

Pour chaque obstacle, observation ou question ouverte, le rapport pourrait joindre une fiche brève. Elle nommerait la classe de preuve : document public, note publique, présentation, intervention sur invitation, discussion protégée ou source externe. Elle préciserait l’entrée dans le processus : document soumis, déclaration d’intérêt, invitation directe ou contribution sans présence.

La fiche indiquerait ensuite si la source est publique, retirée, non attribuée ou protégée ; si elle reste unique, si elle est corroborée indépendamment, contestée ou non résolue ; et quelles incertitudes ou preuves contraires subsistent. Enfin, elle relierait ce matériau à l’affirmation exacte du rapport et qualifierait son autorité : opinion d’un participant, observation de l’atelier, synthèse des organisateurs, avis de l’IAB, question proposée pour un suivi ou travail ultérieur de l’IETF.

Ce registre est une proposition de Daniel Kade, non une règle adoptée par l’IAB. Une annexe ou un tableau suffirait. Les détails sensibles peuvent rester masqués : « une classe de déploiement en environnement réglementé, corroborée par un document public » transmet un statut sans révéler l’organisation.

La dernière qualification est essentielle. Plusieurs participants peuvent partager un constat sans former un consensus de l’IETF. Les organisateurs peuvent dégager un motif sans en faire une position de l’IAB. L’IAB peut conseiller sans fixer le texte ni l’issue d’un groupe de travail. L’ouverture d’un suivi ne doit pas préjuger sa conclusion.

Une autorité institutionnelle réelle, mais bornée

La RFC 2850 attribue à l’IAB la surveillance architecturale et la planification de long terme. Elle l’autorise expressément à réunir des ateliers sur invitation pour examiner en profondeur une question d’architecture. Leur rapport peut conseiller la communauté de l’IETF et l’IESG.

Le mandat doit se lire dans les deux sens. Il ne s’agit pas d’une conversation privée sans conséquence. Un rapport IAB peut orienter l’attention, formuler les problèmes et influencer les priorités. Mais la charte parle d’un conseil, pas d’un remplacement de la procédure de normalisation.

La RFC 9969, consacrée à l’atelier AI-CONTROL, montre une écriture possible. Elle attribue les positions aux participants, non nécessairement à l’IAB, et précise qu’elle restitue les présentations et les notes sans chercher à établir un consensus. Son annexe distingue documents publics, éléments retenus et application de la règle de Chatham House.

Le nouvel atelier n’a pas à reproduire ce précédent ligne par ligne. Il doit en garder la discipline de statut. Un rapport d’atelier est un document informatif issu d’une enquête sélectionnée. Si un groupe de travail examine ensuite une proposition, sa charte, son adoption, le traitement des objections, l’expérience d’implémentation et son propre consensus constituent la chaîne d’autorité pertinente.

La distinction formulée par Heng Lu entre partie prenante et mandant sert ici de règle éditoriale. Participer peut apporter preuve, compétence, avertissement, objection et jugement technique. La présence devient problématique lorsqu’elle est gonflée en autorité sur les absents. Cela n’invite pas à se méfier des experts ; cela impose de ne pas confondre expertise et représentation.

Sources

  1. IAB — Appel à contributions pour l’atelier sur l’authentification post-quantique
  2. IETF — Post-Quantum Authentication: Up Next
  3. RFC 2850 — Charte de l’Internet Architecture Board
  4. RFC 8980 — Rapport de l’atelier IAB sur les effets de la COVID-19 sur les réseaux
  5. RFC 9969 — Rapport de l’atelier IAB AI-CONTROL
  6. Heng Lu — The Multi-Stakeholder Mirage