Résumé

  • draft-ietf-acme-pop-00 propose un parcours optionnel où popKey et une autorisation pop remplacent le CSR de finalisation.
  • La clé du compte authentifie la commande ; la clé du certificat prouve sa possession. Le serveur doit refuser qu'il s'agisse de la même clé.
  • La preuve porte sur les octets exacts de newOrder. L'autorisation d'un nom DNS ou d'un autre identifiant reste un contrôle séparé.
  • Pour ML-KEM, le serveur peut lui-même calculer le MAC attendu : la preuve convient à sa décision, mais ne produit pas une non-répudiation vérifiable par un tiers.
  • Le texte est la révision 00 d'un Internet-Draft de groupe de travail, pas un RFC ni une preuve de déploiement.

Une séparation plus importante que le CSR

Le changement visible est la disparition du CSR dans un chemin particulier. Le changement de contrôle est ailleurs.

Dans newOrder, le client présente la clé publique à certifier sous la forme d'un popKey et ajoute un identifiant pop dont la valeur est vide. La requête est déjà signée par la clé du compte ACME. Le serveur compare alors les deux clés sous leur forme DER canonique et rejette la commande si elles sont égales.

Ce refus dessine deux domaines. La clé de compte dit : « ce compte demande cette opération ». Le popKey dit : « voici la clé qui doit apparaître dans le certificat ». Une preuve ultérieure montre que le participant à cette commande possédait la clé privée correspondante. Fusionner les deux faciliterait peut-être un inventaire, mais confondrait l'administration du service avec l'usage du certificat.

Cette distinction doit rester visible dans les systèmes internes. Le responsable d'un compte ACME, l'opérateur d'un HSM applicatif et l'autorité qui approuve une émission peuvent être trois personnes ou trois services. Un simple voyant « clé validée » efface cette responsabilité.

La commande devient le point de fixation

Le serveur calcule newOrder_hash sur les octets obtenus en décodant le payload JWS, avant toute analyse JSON. Il ne doit pas recréer un objet puis le sérialiser à nouveau. Les octets originaux font foi.

Cette règle évite qu'une preuve soit attachée à une reconstruction qui ressemble à la demande sans lui être identique. Les doublons de clés JSON ou toute interprétation non unique entraînent un rejet. Le serveur conserve atomiquement le popKey, le hash de la commande, une seule autorisation pop et un seul défi pop-01.

Pour une clé de signature, le client signe un préfixe de séparation de domaine, un popNonce aléatoire de 32 octets et le hash de la commande. Pour ML-KEM, le serveur encapsule un secret vers la clé déclarée, publie un challenge_ciphertext, dérive une clé MAC par HKDF-SHA-256 et attend un HMAC du hash de la commande.

Dans les deux cas, modifier les identifiants, la clé ou un autre champ de la commande invalide le contexte de preuve. Le mécanisme évite aussi de réutiliser une ancienne autorisation : chaque commande exige un nouveau défi.

Posséder une clé n'autorise pas un nom

L'identifiant pop est volontairement vide. Il n'est ni un nom de certificat, ni un hash de clé, ni une revendication d'identité. Il demande seulement au serveur de créer une autorisation qui répond à une question étroite : cette commande a-t-elle fourni une preuve de possession du popKey ?

Les noms DNS, adresses de courrier ou autres identifiants continuent à passer par leurs défis ACME habituels. Toutes les autorisations doivent être valides avant que la commande soit prête. Détenir la clé privée sans contrôler le nom ne suffit pas. Contrôler le nom sans détenir la clé privée déclarée ne suffit pas davantage.

La même discipline vaut pour les extensions voisines. Une attestation d'appareil peut dire quelque chose sur un équipement. Un profil peut définir la forme du certificat. Une preuve RATS peut apporter une autre observation. Aucune ne doit absorber silencieusement la proposition des autres.

Le cas KEM change la qualité de la trace

Une signature peut être montrée à un tiers qui vérifie la clé publique et le message. Le MAC du parcours KEM est différent. Le serveur crée l'encapsulation et connaît la valeur attendue. Le client ne peut répondre que s'il sait décapsuler, mais le serveur aurait aussi pu produire le même MAC.

La preuve démontre donc la possession au serveur au moment du défi ; elle ne démontre pas à un auditeur indépendant que seul le client a créé la réponse. Le brouillon le dit explicitement : pas de non-répudiation.

Conserver le ciphertext, le hash de commande, le MAC reçu et l'heure peut être utile pour l'audit interne. Cette trace ne doit pas être présentée comme une signature externe. Les secrets intermédiaires doivent être détruits, les ciphertexts ne doivent pas être réutilisés et le matériel du défi disparaît dès que l'état devient terminal.

La révocation révèle où se trouve le pouvoir

RFC 8555 accepte normalement une révocation authentifiée par la clé du compte ou par la clé privée du certificat. Une clé KEM ne signe pas. Le second chemin n'existe donc pas.

Si la clé de compte est perdue, un certificat KEM peut rester sans moyen de révocation dans le protocole ACME. Une récupération fournie par le prestataire, des certificats courts, une CRL ou OCSP contrôlés séparément peuvent limiter l'exposition. Ce sont des dépendances opérationnelles, non des propriétés automatiques de la preuve.

STAR accentue la concentration. Le popKey initial peut servir à plusieurs renouvellements sans nouveau pop-01. Les certificats STAR ne sont pas révocables individuellement par ce mécanisme ; la clé de compte annule la commande et arrête les émissions futures. Si elle disparaît, le renouvellement peut continuer jusqu'à une intervention ou jusqu'à la date de fin.

Le mot « automatisé » ne réduit donc pas l'autorité. Il la déplace vers la garde, la sauvegarde et la récupération de la clé qui peut encore arrêter la machine.

Ce que la finalisation vide ne prouve pas

Lorsque toutes les autorisations sont valides, la finalisation contient {}. Le serveur doit ensuite placer dans le certificat une clé équivalente au popKey. Les identifiants autorisés viennent de la commande ; les autres champs et extensions restent soumis à la politique de l'AC.

Rien de cela ne prouve que le certificat a été installé, que toutes les répliques le servent, que la clé privée est encore sous contrôle ou qu'un client l'accepte. La preuve de possession est instantanée. Le résultat opérationnel vit plus loin.

La révision 00, publiée le 1er septembre 2026, peut encore changer ou expirer. Elle ne justifie aucune affirmation sur l'adoption d'une AC ou d'un produit nommé, ni sur une émission ou un incident réel.