Résumé

  • Le groupe ACME a transmis draft-ietf-acme-profiles-02 à l’IESG le 21 septembre 2026. L’état « Publication Requested » ne constitue ni une approbation de l’IESG ni la publication d’un RFC.
  • Le nom choisi dans newOrder.profile organise le plan de contrôle de la commande. Les exceptions privées, les règles d’éligibilité et un éventuel invalidProfile à la finalisation empêchent d’en faire une garantie de résultat.

Un automate de certificats aime les noms courts. Il les range dans un fichier, compare une réponse à une valeur attendue et suppose volontiers que deux exécutions portant la même étiquette produiront le même objet. Le projet ACME Profiles rend cette hypothèse vérifiable à certains endroits, mais il montre aussi pourquoi elle reste insuffisante.

Le nom peut être annoncé aujourd’hui dans le Directory d’une AC, accepté sans y figurer lorsqu’un accord privé existe, ou devenir indisponible entre la création de la commande et sa finalisation. Ces situations ne sont pas des incidents inventés : ce sont des branches prévues par le texte.

Où en est réellement le document

Le 21 septembre, l’historique Datatracker a enregistré le passage de Working Group Last Call à « Submitted to IESG for Publication ». La page indique « Publication Requested » côté IESG, Deb Cooley comme Area Director responsable et aucun rendez-vous de téléconférence. Mike Ounsworth a demandé la publication au nom du groupe après la clôture du dernier appel.

Il s’agit d’une étape procédurale, pas d’une décision finale. La version 02 vise le statut Proposed Standard mais n’est pas un RFC. Le shepherd write-up parle d’un consensus faible : l’extension a été jugée simple, peu de participants ont exprimé un soutien marqué, et aucun conflit ni appel n’est signalé. La liste d’implémentations et le déploiement chez Let’s Encrypt décrivent une expérience concrète ; ils ne mesurent pas l’adoption de toute l’industrie.

Une sélection au début de la commande

Le RFC 8555 place déjà la commande avant l’envoi du CSR à finalize. Le projet ajoute à la métadonnée Directory un objet facultatif profiles. Chaque clé est un identifiant court et unique pour ce serveur ; la valeur est une URL donnant une description lisible, éventuellement sous forme de data URL.

Le client peut inclure profile dans newOrder. Si le serveur accepte, l’objet Order renvoyé répète le nom. Le choix des caractéristiques du certificat est donc connu avant le CSR. Selon l’analyse de sécurité du projet, l’AC peut réduire le traitement ASN.1 et laisser au CSR deux fonctions essentielles : porter la clé publique et les subjectAltName.

Ce déplacement ne modifie ni la gestion des comptes ni la validation des identifiants. Il ne crée pas non plus un registre universel des noms. Une annonce appartient à un Directory donné ; la description est un contenu publié par son opérateur, non une sémantique mondiale figée par le protocole.

Quatre preuves à ne pas confondre

L’annonce prouve qu’un serveur a présenté un nom à un moment donné. Elle ne prouve pas qu’un compte peut l’utiliser. Le serveur doit répondre invalidProfile si le profil est incompatible avec la commande. Le texte cite notamment un profil d’authentification de serveur TLS combiné à un identifiant de courrier électronique, ainsi qu’un compte absent d’une liste d’autorisation.

L’absence d’annonce ne prouve pas toujours l’impossibilité. Le client ne devrait pas demander un profil absent et le serveur devrait le refuser. Le serveur peut néanmoins l’accepter dans des circonstances exceptionnelles : profil privé convenu hors protocole, ou remplacement d’un certificat ancien après une révocation massive. La preuve doit donc conserver à la fois l’état public du Directory et la base de l’exception.

L’absence de champ dans la requête ne prouve pas non plus qu’aucun profil n’a été choisi. Le serveur qui implémente l’extension est invité à en sélectionner un et à l’associer à la commande. C’est la réponse Order qui fixe alors le choix observé.

Enfin, l’acceptation de la commande ne prouve pas la délivrance. Si l’AC n’est plus disposée à émettre selon le profil au moment de finalize, elle doit renvoyer invalidProfile. Le projet recommande de laisser expirer les commandes existantes avant un arrêt, mais il conserve ce cas d’erreur parce que la politique peut évoluer pendant la durée d’une commande.

Les pratiques d’un opérateur montrent la dimension temporelle

Let’s Encrypt demande de consulter le Directory courant pour connaître la liste canonique de ses profils. Sa documentation précise que tous ne sont pas disponibles dans tous les environnements et que certains peuvent être réservés à des comptes autorisés.

Les profils classic, tlsserver et shortlived ne se distinguent pas seulement par leur nom : durées d’autorisation et de commande, durée du certificat, types d’identifiants et champs du certificat varient. L’ancien tlsclient n’est plus disponible depuis le 8 juillet 2026. tlsserver est passé à des certificats de 45 jours le 13 mai, tandis que d’autres changements de durée sont annoncés pour classic.

Ces faits démontrent qu’un opérateur peut faire évoluer son offre. Ils ne permettent pas d’attribuer les mêmes noms, les mêmes valeurs ou le même calendrier à une autre AC.

Construire une chaîne de décision

Le premier enregistrement est le Directory brut, avec son URL et l’heure de collecte. Le deuxième est la description suivie par le client, avec une empreinte du contenu. Le troisième relie le compte, les identifiants et le nom demandé à la décision d’éligibilité. Le quatrième conserve la réponse Order et le nom répété par le serveur.

La finalisation mérite sa propre pièce : empreinte du CSR, statut de réponse et problème ACME éventuel. Si un certificat est délivré, son empreinte et ses propriétés analysées montrent le résultat signé. Si l’objectif est le déploiement, une observation distincte du service en production est nécessaire ; délivrer et installer restent deux événements.

Cette séparation garde au nom son utilité sans lui attribuer un pouvoir fictif. Il relie les étapes d’une transaction documentée. Il ne garantit ni que la description restera identique, ni qu’un autre serveur comprendra la même chaîne de caractères de la même manière.

Sources

  1. État courant du projet dans le Datatracker
  2. Historique Datatracker
  3. Texte de draft-ietf-acme-profiles-02
  4. Demande de publication adressée au groupe ACME
  5. Shepherd write-up
  6. RFC 8555
  7. Documentation des profils Let’s Encrypt
  8. Annonce ACME Profiles de Let’s Encrypt
  9. Calendrier de réduction des durées
  10. Annonce du Working Group Last Call
  11. Clôture du Working Group Last Call
  12. Suivi de l’implémentation Boulder
  13. Compte rendu ACME de l’IETF 126