Résumé

  • La pull request 679, encore marquée Draft au 2 septembre 2026, ajouterait ML-DSA-44, ML-DSA-65 et ML-DSA-87 aux TLS Baseline Requirements pour les certificats, CRL et réponses OCSP.
  • Le préambule nomme des clients SDK, des systèmes embarqués et IoT, des middlewares d’entreprise et des applications appuyées sur les magasins de confiance des systèmes d’exploitation. Il précise que le texte n’obligerait aucun root store à faire confiance à ML-DSA et ne changerait pas la signature des SCT.
  • La charte du SCWG couvre les certificats TLS de serveurs accessibles par Internet, mais définit le Certificate Consumer votant par un logiciel destiné à naviguer sur le Web de manière sûre. L’émetteur votant est lui aussi qualifié par l’acceptation de ses certificats dans un tel navigateur.
  • L’exclusion expresse des PKI d’entreprise strictement internes est plus étroite que « tout usage hors navigateur ». La portée publique reste donc interprétable ; aucun extrait isolé ne permet de trancher honnêtement.
  • Les minutes de Tokyo de mars 2025 et les commentaires de la PR montrent que la difficulté était connue. Ils consignent des positions, non une décision collective.
  • Un reçu de mandat devrait identifier les bénéficiaires, la clause de charte, la représentation, l’invariant commun, les droits des root stores et de CT, les preuves d’exécution et le lieu de réexamen.

La justification et l’électorat ne parlent pas exactement des mêmes logiciels

SC-106 devient intéressant avant même d’examiner ses OID. Son préambule explique pourquoi le profil serait nécessaire : nombre de parties utilisatrices ne disposeraient pas d’une voie pratique vers l’authentification post-quantique dans l’infrastructure X.509 de confiance publique. La liste est concrète : clients de services construits avec des SDK, appareils embarqués et IoT, middlewares d’entreprise, applications utilisant les magasins gérés par les systèmes d’exploitation.

La charte du Server Certificate Working Group organise pourtant le vote du côté consommateur autour d’un autre objet. L’organisation admissible doit produire pour le grand public un logiciel destiné à naviguer sur le Web de manière sécurisée. L’émetteur admissible doit, de son côté, émettre des certificats de serveurs Web ouverts qui sont acceptés par un navigateur produit par un membre consommateur.

Il ne s’ensuit pas que les ingénieurs de navigateurs ignorent les systèmes d’exploitation, les bibliothèques TLS ou les clients serveur-à-serveur. Plusieurs organisations présentes opèrent plusieurs couches. Il ne s’ensuit pas davantage qu’un besoin hors Web devient représenté parce qu’un expert qui le comprend participe à la discussion. L’expertise décrit un problème ; le mandat dit quelle instance peut fixer le minimum commun et pour quelle classe d’utilisateurs.

La distinction de Lu Heng entre partie prenante et mandant est utile ici. Être affecté, compétent ou présent ne suffit pas à établir une délégation. Le dossier devrait donc préciser si SC-106 est d’abord un minimum pour le Web dont d’autres logiciels profiteront, un travail annexe autorisé par la charte, ou un profil de confiance publique pensé pour plusieurs catégories dont certaines ne disposent pas du vote consommateur.

Le diff est précis et son autorité ne doit pas être élargie

Le commit figé eefc670… ajoute les trois jeux de paramètres de FIPS 204, la validation de l’encodage des clés, les usages permis dans un certificat d’abonné et des identifiants d’algorithmes exacts. HashML-DSA serait interdit ; seule la variante dite « pure » de ML-DSA serait autorisée.

Le texte impose ensuite une correspondance dans les deux sens. Une clé publique d’abonné ML-DSA devrait être certifiée par une signature ML-DSA. Une signature de certificat ML-DSA ne pourrait certifier qu’une clé publique ML-DSA. La deuxième règle ne s’appliquerait pas aux CRL ni aux réponses OCSP, qui ne certifient pas une clé publique.

Le préambule sépare déjà trois autorités. Le SCWG peut autoriser un profil d’émission. Un opérateur de magasin racine reste libre de ne pas accepter la hiérarchie. Un opérateur de Certificate Transparency conserve la maîtrise de l’algorithme qui signe les Signed Certificate Timestamps. Cette séparation est substantielle : l’entrée de ML-DSA dans les BR ne signifie ni confiance, ni journalisation, ni chemin accepté, ni déploiement.

Elle appelle cependant une question vérifiable. Quel obstacle commun le profil retire-t-il pour chacun des clients cités ? S’agit-il de l’audit d’une CA, de la politique d’un root store, de la génération du certificat, de la construction de chemin, de la mise à jour d’un magasin ou de l’absence d’un format partagé ? Le dossier public ne fournit ni inventaire des déploiements bloqués, ni mesure des populations, ni preuve qu’une même contrainte convient à tous.

Le numéro SC-106 ne transforme pas encore la PR en scrutin

Au seuil de recherche, la page GitHub indiquait Open et Draft, avec un seul commit. La page officielle des scrutins du SCWG ne répertoriait pas SC-106 dans le vote, l’examen IPR, la discussion, les projets en considération ou l’historique. Aucun avis formel ne permettait d’attribuer des promoteurs, une fenêtre de discussion, une période de vote, un résultat ou une date d’effet.

Le statut exact est donc « projet de pull request ». Le corps peut employer le mot ballot pour expliquer l’intention de ses auteurs ; cela ne remplace pas l’acte par lequel le Working Group ouvre sa procédure.

La chronologie doit rester additive. Un auteur propose un diff. Une version déterminée entre éventuellement en discussion. Les deux classes votent. L’examen de propriété intellectuelle suit le résultat applicable. Une Final Maintenance Guideline est publiée avec ses dates. Les root stores, CA, journaux et clients prennent ensuite leurs décisions. Une première PR ne peut recevoir rétrospectivement l’autorité de toute la chaîne.

Le diff immuable conserve néanmoins une grande valeur : il fixe ce qui était proposé le 26 août. Si le texte change, la version ancienne reste un état historique et non une fausse version finale.

Une charte à la fois large par l’activité et étroite par le vote

Lire la charte honnêtement exige de conserver ses deux côtés. Sa clause de portée autorise la rédaction de Baseline Requirements et de bonnes pratiques pour des certificats TLS servant à authentifier des serveurs accessibles par Internet. Elle autorise aussi les mises à jour contre les menaces émergentes et les activités annexes aux missions principales. Cette formulation dépasse un produit de navigateur particulier.

Mais la définition des membres dit qui porte la voix institutionnelle. Le consommateur votant est rattaché à la navigation Web. L’émetteur votant est qualifié par l’acceptation dans un navigateur d’un membre consommateur. Des SDK, appliances et middlewares peuvent être techniquement concernés sans constituer eux-mêmes la classe qui approuve le texte.

La clause hors portée ne résout pas le conflit. Elle exclut les PKI d’entreprise destinées uniquement à un usage interne lorsque leur racine n’est distribuée par aucun Certificate Consumer, ainsi que plusieurs usages primaires comme S/MIME et la signature de code. Elle ne dit pas que tout client non navigateur utilisant une racine système est exclu. Elle prouve plutôt que la charte sait nommer des frontières précises.

On ne peut donc déclarer ni « tout hors Web est interdit », ni « tout certificat serveur Internet appartient forcément au SCWG ». Une interprétation publique doit relier la catégorie visée à une clause, indiquer qui peut l’interpréter et disposer les objections. À défaut, une règle d’encodage déciderait silencieusement de la portée institutionnelle.

Tokyo avait déjà décrit la fracture

Les minutes de la réunion 64, en mars 2025, consacrent une longue section à la portée des TLS BR. Des participants y discutent des navigateurs, des magasins des systèmes d’exploitation, des connexions serveur-à-serveur, des PKI privées et de l’idée d’un nouveau groupe de travail.

Deux réalités opérationnelles s’opposent dans le compte rendu. Pour les uns, les politiques racines des navigateurs donnent aux BR leur réalité et leur agilité ; les usages non Web ne devraient pas ralentir cette évolution. Pour les autres, les mêmes racines servent à des applications et systèmes d’exploitation qui n’ont pas d’alternative, et une règle trop centrée sur le navigateur risque de fragmenter leurs chaînes.

Le résumé des minutes ne choisit pas entre ces voies. Il constate l’existence des deux perspectives et l’inconfort de la confusion. Il ne modifie pas la charte. Il prouve simplement que l’objection de 2026 n’est pas un incident inventé pour ML-DSA.

La discussion de la PR reprend les mêmes éléments. Un commentaire parle explicitement de cas « non WebPKI ». Ben Wilson insiste sur le chemin réellement construit et accepté par la partie utilisatrice. Un commentaire ultérieur provenant d’un participant Chrome distingue deux directions de chaîne mixte, conteste l’adéquation de la portée et propose d’examiner un groupe distinct. Ce sont des contributions nommées. Ni leur nombre ni les réactions GitHub ne valent décision.

La pureté d’une chaîne n’est pas la propriété d’un profil seul

Le projet avance qu’un lien classique dans le chemin présenté limite ce chemin à une assurance classique. La proposition en déduit des appariements stricts entre clé et signature. L’objection répond qu’une partie utilisatrice peut accepter un chemin entièrement post-quantique et ignorer une alternative classique ; l’existence de plusieurs chemins ne change pas les signatures du chemin choisi.

RFC 5280 fournit la séparation fondamentale. Un chemin prospectif et les informations de trust anchor sont des entrées de la validation. La sélection de l’ancre relève d’une politique, et les chemins ne doivent pas tous partir de la même ancre. Un profil d’émission peut interdire une structure ; il ne sélectionne pas à lui seul le chemin utilisé par un client.

Cela ne suffit pas pour dire que les deux interdictions du projet sont mauvaises. Une CA classique qui signe une clé d’abonné post-quantique peut créer un problème différent d’une CA post-quantique qui signe temporairement une clé classique. La capacité des journaux, la résistance au downgrade, le signal des racines et la compatibilité ne sont pas une seule propriété.

La bonne question est donc : quel invariant doit être commun ? Si la règle protège la capacité CT du Web, elle doit nommer cette surface. Si elle garantit qu’un chemin étiqueté post-quantique ne contient aucune signature classique, elle doit définir le chemin et l’étiquette. Si elle sert une transition hors Web, elle doit montrer les clients et versions qui l’implémentent. Une formule unique ne doit pas emprunter l’autorité de trois problèmes différents.

Les implémentations en cours démontrent plusieurs chemins

La feuille de route de Chromium décrit une transition Web en étapes, avec négociation de certificats, identifiants classiques et post-quantiques associés, résistance au downgrade et retrait très lointain des options classiques. Pour la confiance publique Web, Chrome privilégie les Merkle Tree Certificates plutôt que des certificats X.509 ML-DSA traditionnels.

Son programme de test rend la distinction visible. Chrome annonce le support des certificats X.509 ML-DSA dans les hiérarchies privées à partir de Chrome 150. Pour les MTC, il distribue un magasin de test séparé, dont les cosignataires sont explicitement étiquetés comme non fiables en production. Les conditions de test, de journalisation et de mirroring appartiennent à ce profil précis.

Ce n’est ni une victoire de Chrome sur le Forum, ni une solution universelle pour l’IoT. C’est une preuve de running code : plusieurs ensembles de compatibilité peuvent exister sans qu’un document les transforme tous en une politique unique.

FIPS 204 définit l’algorithme. Le profil de certificat définit l’encodage et l’émission. La politique racine décide de la confiance. CT décide de l’admission et de la transparence. Le client choisit un chemin. L’observation de déploiement dit ce qui fonctionne. Conserver ces verbes distincts évite de faire d’une norme cryptographique un mandat institutionnel.

Le reçu de mandat minimal

Un document court suffirait. Il devrait conserver l’identité immuable de la proposition et son état procédural ; énumérer les catégories de clients visées ; associer chacune à la clause de charte pertinente ; indiquer lesquelles disposent d’un vote, d’une participation consultative ou d’aucune voie formelle.

Il devrait ensuite séparer cinq lignes techniques : format de clé et de signature, assurance du chemin, résistance au downgrade, charge CT, admission par un root store. Pour chaque ligne : invariant recherché, propriétaire de la décision, preuve disponible, incertitude et possibilité de décision locale.

Enfin, il devrait comparer les lieux possibles : continuer au SCWG avec une interprétation explicite ; clarifier ou amender la charte ; créer un autre groupe du Forum ; ou laisser les programmes racines tester des profils limités. Une date de revue, un seuil d’adoption et un mécanisme de retrait éviteraient qu’une restriction de transition ne devienne permanente par inertie.

Le reçu ne donne pas un droit de veto à chaque fabricant d’appareil. Il empêche seulement de transformer l’absence de représentation en représentation implicite.

Ce que les sources ne permettent pas d’affirmer

Au 2 septembre, rien ne permet de dire que SC-106 est adopté, invalide, inutile ou techniquement final. Le SCWG n’a pas publié d’interprétation collective de sa charte. Aucun recensement n’établit la demande réelle des classes nommées. Aucun résultat n’annonce qu’un root store public acceptera ces certificats ou que CT supportera un volume déterminé.

La stratégie Chrome n’est pas une décision du Forum. Le commentaire Mozilla ne tranche pas la cryptographie. Le préambule de la PR n’engage pas les systèmes d’exploitation. Une absence sur la page des ballots prouve le statut public observé, non une intention cachée.

Cette prudence n’affaiblit pas l’enquête. Elle montre qu’il est encore peu coûteux d’établir le mandat avant que les audits, outils d’émission et marchés publics ne présentent le profil comme un consensus de l’industrie.

Un profil plus étroit peut être plus durable

Si le Working Group conclut que sa mission Internet-TLS englobe ce profil, il peut publier le raisonnement et limiter la revendication de représentation. Si les besoins des systèmes, SDK et appareils imposent des contraintes différentes du Web, un groupe distinct peut leur donner une surface de décision plus claire. Si les pilotes existants suffisent, la normalisation commune peut attendre les mesures.

Ces options ne s’opposent pas à l’innovation. Elles empêchent seulement qu’une solution techniquement commode acquière, par son emplacement, une autorité qu’aucun texte n’a explicitée.

SC-106 sépare déjà le profil du root store et du SCT. Il reste à séparer le bénéficiaire du corps votant. Nommez la partie utilisatrice, la clause et le droit qui demeure local : le profil pourra alors rester aussi précis que son mandat.

Sources

  1. Lu Heng, « The Multi-Stakeholder Mirage »
  2. Lu Heng, « Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption »
  3. CA/Browser Forum, pull request 679 — SC-106
  4. Comparaison immuable de SC-106
  5. TLS Baseline Requirements proposés au commit figé
  6. Charte du Server Certificate Working Group
  7. Minutes de la réunion SCWG 64
  8. Bylaws du CA/Browser Forum
  9. État des ballots du SCWG
  10. NIST FIPS 204
  11. RFC 5280, section 6
  12. Chromium, feuille de route de l’authentification HTTPS post-quantique
  13. Instructions de test du Chrome Quantum-resistant Root Program