Résumé

  • Le 6 septembre, le groupe JOSE a transmis à l’IESG son projet de dépréciation de none et RSA1_5. La publication est demandée, mais il n’y a encore ni approbation de l’IESG, ni RFC, ni modification exécutée par l’IANA.
  • Le texte imposerait la désactivation par défaut et interdirait ces algorithmes dans les nouvelles spécifications, tout en autorisant une réactivation limitée à certains objets ou opérations. La durée et la preuve de ces exceptions restent du ressort de chaque exploitant.

Une transmission à l’IESG, pas une règle déjà en vigueur

L’événement du 6 septembre 2026 est procédural mais substantiel. L’historique du Datatracker indique que draft-ietf-jose-deprecate-none-rsa15-05 est passé à « Submitted to IESG for Publication » et que son état IESG est devenu « Publication Requested ». Deb Cooley en est l’Area Director responsable.

Ce dossier ne permet pas d’écrire que la décision est prise. La révision 05, datée du 23 juin, reste un Internet-Draft. Elle peut encore être examinée, amendée ou abandonnée. Le registre JOSE de l’IANA affichait toujours, à la date de vérification, none comme Optional et RSA1_5 comme Recommended-. Ce décalage est normal tant que la procédure n’est pas achevée ; il ne prouve ni retard ni refus.

Le projet propose de mettre à jour le RFC 7518, mais son effet ne se résume pas à une étiquette. Il distribue quatre consignes selon l’acteur. Les responsables de bibliothèques JOSE DEVRAIENT déprécier la prise en charge. Les développeurs d’applications DOIVENT la désactiver par défaut. Une application PEUT réactiver un algorithme pour les seuls objets ou opérations qui en ont un besoin précis, jamais globalement. Enfin, une nouvelle spécification fondée sur JOSE NE DOIT PAS autoriser l’un ou l’autre.

Le choix du mot Deprecated est intentionnel. Le projet refuse le statut Prohibited : les spécifications et applications existantes peuvent continuer, tout en étant encouragées à adopter une solution de remplacement. Il précise aussi que les signatures RSA RS256, RS384 et RS512 ne sont pas concernées. RSA1_5 désigne ici le mécanisme de gestion de clé RSAES-PKCS1-v1_5 de JWE.

La compatibilité explique l’exception, pas son éternité

La justification de sécurité est nette. Avec none, un JWS ne porte ni signature ni MAC. Le RFC 7518 interdisait déjà son acceptation par défaut, mais le projet recense une série de vulnérabilités nées d’implémentations qui l’ont accepté par erreur. Pour RSA1_5, il rappelle les faiblesses du chiffrement RSA avec bourrage PKCS #1 v1.5, connues depuis l’attaque de Bleichenbacher en 1998, et cite notamment OAEP comme voie de remplacement.

Le passé ne disparaît toutefois pas avec une nouvelle recommandation. OpenID Connect a prévu des usages historiques de jetons d’identité non signés transportés sous TLS et d’objets de requête non signés. Le rapport du shepherd raconte qu’après les échanges d’IETF 124, un appel au consensus de deux semaines, en février 2026, a produit un compromis : reconnaître ces cas sans renoncer à la dépréciation.

Le même rapport indique du soutien et aucune opposition pendant un Working Group Last Call prolongé. À IETF 126, un sondage a compté 27 voix favorables à la publication, zéro opposée et huit sans opinion. C’est un élément de consensus pour avancer le texte, pas un recensement des logiciels ou des dépendances encore actives.

Ce que l’IANA sait, et ce qu’elle ne doit pas savoir

Un registre central peut dire ce qu’un identifiant signifie, qui contrôle sa définition, quelle référence le documente et quel niveau de recommandation lui est attaché. Le projet ajouterait aussi des critères de sécurité aux instructions des experts désignés : EUF-CMA pour les signatures et MAC de JWS, IND-CCA2 pour l’ensemble du processus JWE lorsqu’ils examinent une gestion de clé, et AEAD pour le chiffrement de contenu. Ces critères ne s’appliqueraient pas aux inscriptions demandées directement comme Deprecated ou Prohibited.

En revanche, l’IANA ne voit pas qu’une application a réactivé none pour une catégorie d’objet héritée. Elle ne voit pas non plus qu’un partenaire exige encore RSA1_5. Le projet ne crée ni protocole de télémétrie, ni registre d’exceptions, ni mécanisme de migration ; le shepherd le dit explicitement.

Il ne faudrait pas combler ce vide en transformant l’IANA en superviseur des configurations privées. La décision opérationnelle appartient au système qui comprend l’objet, le partenaire et le risque de rupture. Mais cette liberté locale doit laisser une trace locale vérifiable.

Une fiche d’exception devrait lier l’algorithme exact, l’usage JWS ou JWE, l’objet ou l’opération autorisés, le service, le responsable, la dépendance bloquante, les mesures compensatoires, la preuve que le réglage global reste désactivé, la dernière utilisation observée, la cible de migration, la date de réexamen et l’échéance. Il s’agit de ma recommandation éditoriale, non d’une obligation du projet, du RFC 7518, de l’IANA, du NIST ou d’OpenID Connect.

Deux horloges pour une dépréciation réelle

L’horloge publique suit le texte : examen par l’Area Director, éventuel IETF Last Call, évaluation de l’IESG, possible RFC, puis modification du registre. La page récapitulative du Datatracker affiche encore une intention « Internet Standard », tandis que le shepherd demande « Proposed Standard » et qualifie la première métadonnée d’erronée. C’est un état documentaire à résoudre, pas la preuve d’un vice de procédure.

L’horloge locale commence au moment où une application rouvre délibérément le chemin. Sans échéance, le « besoin précis » survit à la dépendance. Sans mesure de dernière utilisation, une équipe ne sait pas si elle protège une compatibilité vivante ou un interrupteur oublié. Sans responsable, chaque mise à jour de bibliothèque oppose brutalement continuité et sécurité.

La spécification initiale minimale de Heng Lu aide à placer la frontière : le défaut sûr et l’interdiction faite aux nouvelles spécifications appartiennent à la couche commune ; l’exception reste locale. Sa primauté du code opérationnel ajoute le test : la publication modifie le référentiel, tandis que la configuration et les transactions observées prouvent ce qui fonctionne réellement.

Le prochain progrès ne consiste donc pas à épaissir le centre. Il consiste à rendre chaque exception locale nominative, limitée, mesurée et mortelle.

Sources

  1. IETF Datatracker — dépréciation de none et RSA1_5
  2. Historique Datatracker et rapport du shepherd
  3. Internet-Draft, révision 05
  4. RFC 7518 — JSON Web Algorithms
  5. IANA — registre JOSE
  6. RFC 5116 — chiffrement authentifié
  7. RFC 8017 — PKCS #1 version 2.2
  8. NIST SP 800-131A, révision 2
  9. OpenID Connect Core 1.0
  10. Dépôt source du projet
  11. Heng Lu — Minimum Initial Specification
  12. Heng Lu — Running-Code Primacy