Résumé

  • La révision 01 du projet individuel ACME, publiée le 28 octobre, retire le profil strict de la révision 00. Celui-ci imposait des signatures postquantiques ou hybrides pour le serveur TLS et les requêtes JWS, sans repli sur une signature classique seule.
  • Le nouveau §4.2 permettrait au serveur de ne plus implémenter ES256, pourtant obligatoire dans la RFC 8555. S’il le conserve, il peut accepter les requêtes JWS classiques pendant une période de transition qu’il choisit.

Deux serveurs, une même étiquette, deux politiques

Un client automatise l’émission d’un certificat. Son premier serveur ACME refuse désormais la signature ES256 de son compte ; le second la reçoit encore. Les deux peuvent pourtant présenter leur canal TLS comme prêt pour l’ère postquantique. La divergence ne se lit ni dans le nom du mécanisme ni dans la beauté de la connexion chiffrée. Elle apparaît au moment précis où le serveur décide quelle preuve d’identité il accepte pour une commande de certificat.

La première version distinguait un profil « strict ». Pour l’authentification du serveur TLS comme pour celle des requêtes JWS, il exigeait une signature postquantique ou hybride et ordonnait le rejet du repli classique. La nouvelle version efface cette section. Son mécanisme conserve l’échange de clés postquantique ou hybride sur toutes les connexions TLS concernées et le support des nouvelles signatures. L’authentification classique seule peut néanmoins subsister pendant une transition explicitement bornée. Le texte ne fournit pas une date commune de fermeture.

Le déplacement du pouvoir est écrit en toutes lettres au §4.2. En juin, plusieurs variantes ML-DSA et une combinaison hybride figuraient parmi les algorithmes à implémenter ; ES256 restait lui aussi exigé. En octobre, le serveur peut choisir parmi les algorithmes JWS inscrits au registre JOSE, sans jeu ni paramètres imposés. Il peut même abandonner ES256. S’il le garde pour ses anciens clients, il peut continuer à accepter leurs signatures classiques pendant la période qu’il aura définie. Pour les opérateurs de PKI, le calendrier devient une règle de service, pas une propriété automatique du mot « postquantique ».

Le projet laisse une couture visible. L’introduction d’octobre parle de signatures postquantiques et hybrides obligatoires à implémenter, tandis que le §4.2 emploie « MAY » et affirme ne fixer aucun algorithme JWS particulier. Il faudra accorder ces phrases avant de prétendre disposer d’un test de conformité partagé. La fiche IETF classe encore le texte comme projet individuel, sans statut de norme adoptée.

Le canal TLS protège notamment les messages ACME capturés aujourd’hui contre un déchiffrement futur. La signature JWS authentifie la demande envoyée maintenant avec la clé du compte. Un canal renforcé peut donc transporter une demande dont la signature ancienne reste acceptée. Ce n’est pas le tunnel qui décide de délivrer le certificat ; c’est le serveur qui vérifie l’ordre. Un essai public indiquant les algorithmes acceptés, la date de retrait d’ES256 et le rejet effectif des demandes classiques montrerait où la porte se ferme.

Sources : révision d’octobre ; révision de juin ; RFC 8555 ; statut IETF.