Résumé

  • L’IETF a recharté LAMPS pour entretenir PKIX et S/MIME et traiter notamment l’établissement de clés hybride, les doubles signatures et des échanges de certificats plus légers.
  • Une charte autorise un ordre du jour. Elle n’adopte pas un projet, ne publie pas un RFC, ne livre pas de code et n’installe aucune ancre de confiance chez les utilisateurs.

Le certificat allégé ne décide pas de la confiance

La phrase la plus instructive de la charte décrit un certificat X.509 non signé. Les signatures post-quantiques étant volumineuses, une autosignature peut représenter un coût sensible lorsqu’un appareil reçoit déjà son ancre par une voie de configuration protégée.

Le raccourci serait de conclure que la signature est retirée avec la sécurité. Or l’autosignature d’une racine ne convainc pas, à elle seule, une partie utilisatrice de lui faire confiance. RFC 5280 traite les informations d’ancre comme une donnée d’entrée de la validation, acquise par une procédure fiable hors bande. RFC 5914 définit en outre un format autonome, TrustAnchorInfo.

L’autorité réside donc dans une autre chaîne : qui a autorisé l’installation, comment l’objet a été authentifié, quelle clé et quel nom ont été fixés, quelles contraintes ont été conservées, quelle ancienne ancre a été remplacée et quel retour arrière reste possible. Un conteneur sans autosignature peut être raisonnable si cette chaîne est solide. Il devient dangereux si la réduction de taille efface l’identité de l’installateur.

Il s’agit pour l’instant d’un exemple de problème admis dans le périmètre du groupe. La charte ne normalise pas ce conteneur et n’atteste aucun déploiement.

Le 21 août, l’IETF a déplacé une frontière institutionnelle

Le 21 août 2026 à 20 h 40 UTC, l’IETF a annoncé la nouvelle charte du groupe Limited Additional Mechanisms for PKIX and SMIME. Datatracker classe LAMPS comme actif et indique la révision 08 comme texte approuvé.

Le mandat rassemble deux ensembles. Le groupe entretient des mécanismes issus des anciens travaux PKIX et S/MIME — notamment CMP, CMC, EST, S/MIME et PKIX — et prépare ces environnements aux algorithmes susceptibles de remplacer ou d’accompagner RSA, Diffie-Hellman, ECDSA, ECDH et EdDSA.

La permission n’est pas illimitée. Un nouveau sujet doit disposer d’un public de déploiement identifiable et d’au moins une approche suffisamment précise pour que le groupe puisse juger son adoption. Ces critères prouvent qu’une question mérite une instance de travail, pas que sa réponse est correcte. Une proposition détaillée peut échouer à l’examen de sécurité ; ses utilisateurs pressentis peuvent diverger sur les erreurs ; le groupe peut refuser l’adoption ou ne pas parvenir au consensus.

Les normes NIST laissent entière la question de l’intégration

FIPS 203, 204 et 205 définissent respectivement ML-KEM, ML-DSA et SLH-DSA. La charte prévoit aussi des algorithmes évalués par le CFRG. Ces références donnent une base cryptographique, mais pas les profils complets nécessaires aux certificats, aux objets CMS, aux protocoles d’enrôlement ou aux logiciels S/MIME.

Il reste à spécifier les encodages, les paramètres, les profils de certificats, les règles de validation et d’erreur, les vecteurs d’essai et les comportements opérationnels. La charte prévoit des identifiants d’objet attribués par NIST ou l’IANA. Un OID rend une construction nommable dans un objet structuré ; il ne met pas à jour une bibliothèque et n’établit aucune politique d’acceptation.

Une déclaration « prêt pour le post-quantique » devrait donc être décomposée : norme algorithmique, profil protocolaire, identifiant, état du document, implémentation, configuration, objet émis, objet accepté et résultat observé. L’annonce n’est que l’un des premiers maillons.

L’hybridation exige une règle, pas deux étiquettes

Pour l’établissement de clés hybride, LAMPS doit définir formats, identifiants, enrôlement et pratique opérationnelle. Le principe consiste à combiner des secrets provenant d’un ou plusieurs algorithmes traditionnels avec ceux d’un ou plusieurs algorithmes post-quantiques admissibles.

Juxtaposer les valeurs ne suffit pas. Les deux extrémités doivent partager un encodage et une fonction de dérivation sans ambiguïté. La charte cite HKDF, une méthode conforme à NIST SP 800-56C ou une fonction évaluée par le CFRG. RFC 5869 sépare extraction et expansion, ce qui oblige à expliciter le sel, le contexte et la longueur de sortie.

La propriété attendue en cas de défaillance d’un composant doit également être écrite : que reste-t-il si un algorithme est cassé, mal implanté, substitué ou omis ? Le projet composite KEM est encore un Internet-Draft actif. Il prouve un travail de spécification, non une entente finale entre produits sur l’encodage, le rejet et la transition.

Deux signatures multiplient les états de politique

Le volet « double signature » associe des algorithmes traditionnels et post-quantiques. Le projet correspondant reste lui aussi un Internet-Draft actif.

Un vérificateur doit savoir si tous les composants sont obligatoires, si une politique transitoire peut n’en accepter qu’un, comment les identifiants lient clés et signatures, et comment réagir lorsqu’une bibliothèque comprend l’enveloppe mais pas un composant. Sans règle ferme, une dégradation peut transformer une protection transitoire en autorité traditionnelle seule.

L’autorité de certification, le producteur CMS, le client de messagerie, la bibliothèque et l’application finale peuvent chacun prendre une décision différente. Le fonctionnement réel est leur intersection. Compter les certificats portant un nouvel identifiant ne démontre ni le traitement par les intermédiaires ni l’acceptation par les parties utilisatrices.

Les mois de la charte ne sont pas des garanties

L’annonce mentionne octobre 2026 pour les signatures composites dans PKIX et CMS, novembre pour le KEM composite et décembre pour CAA Security. Ce calendrier sert à organiser et à rendre visibles les retards. Il ne signifie ni fin du groupe, ni IETF Last Call, ni approbation IESG, ni publication en RFC, ni disponibilité d’un produit.

Un retard peut signaler une difficulté technique, une controverse ou un manque de relecteurs, sans condamner l’algorithme sous-jacent. Inversement, un document livré à temps ne prouve pas que les appareils contraints supportent sa taille ou qu’un magasin de confiance sait revenir en arrière proprement.

Il faut donc suivre séparément le calendrier institutionnel et les preuves d’exécution.

Le mandat s’arrête à la frontière du groupe

Une charte rend une question recevable, attire des experts et donne un domicile cohérent aux documents. Elle ne transforme pas LAMPS en autorité de certification, en régulateur d’algorithmes ou en administrateur distant des magasins de confiance.

NIST maîtrise ses normes, les autorités désignées attribuent les identifiants, le processus IETF décide du statut documentaire, les fournisseurs livrent du code et les opérateurs configurent l’acceptation. Même représentée conformément à un RFC, une ancre installée reste une délégation locale.

Pour chaque sujet, le dossier devrait conserver la révision de charte, le problème, le public de déploiement, la révision du projet, l’adoption, les objections, le consensus, l’analyse de sécurité, les dépendances, les identifiants, les vecteurs d’essai, les implémentations indépendantes, l’enrôlement, la configuration des utilisateurs, le repli et les échanges mesurés.

Sources