Résumé

  • La révision 05 du profil Authority Token pour JWTClaimConstraints demande aux clients et serveurs ACME de transporter et comparer une valeur DER opaque, sans en interpréter le sens métier.
  • L’Autorité de jetons évalue la contrainte selon les règles du domaine ; l’écosystème qui déploie décide quels certificats d’émetteur le serveur ACME doit considérer comme fiables.
  • Le paramètre facultatif token-authority indique au client où chercher un jeton. Il n’entre pas dans la validation du serveur, qui exige plutôt un certificat x5u ou x5c déjà admis dans sa configuration de confiance.
  • Le texte est encore un Internet-Draft du groupe de travail. Réussir ses contrôles ne constitue ni une preuve universelle d’identité ni un jugement juridique sur le droit d’émettre.

La version 05 sépare l’encodage, le sens et le mandat

Les auteurs ont annoncé la révision 05 le 5 septembre 2026. Elle répond à une revue du président d’ACME qui demandait notamment à quels développeurs s’adressaient les exigences et comment traiter plusieurs éléments ambigus. La réponse de Chris Wendt recense les clarifications sur le public du document, la confiance dans l’émetteur et l’usage de token-authority.

Le profil sert aux autorités de certification de l’écosystème Secure Telephone Identity. Il automatise, au moyen d’ACME, la preuve d’autorité sur une extension JWTClaimConstraints susceptible de borner les affirmations portées par un certificat. RFC 9448 définit cette extension. RFC 8226 et RFC 9118 décrivent les certificats et les contraintes de déclarations qui donnent son contexte au nouveau profil.

Trois fonctions ne doivent pas être confondues. Le client ACME présente l’identifiant et obtient le jeton. Le serveur ACME vérifie la réponse au défi. L’Autorité de jetons décide auparavant si la contrainte demandée est recevable selon les règles propres au domaine, puis signe l’autorisation.

Pour le client et le serveur, la valeur DER de la contrainte est une suite d’octets opaque encodée en base64url. Ils la transportent et exigent une identité exacte, octet par octet. Ils ne décomposent pas mustInclude, permittedValues ou mustExclude afin de juger leur pertinence. Ce jugement sémantique appartient à l’Autorité de jetons.

La limite protège l’architecture d’une fausse promotion. Le protocole ACME défini par RFC 8555 sait automatiser la gestion de certificats. Il n’acquiert pas, par cette capacité, le mandat de définir les droits associés aux contraintes téléphoniques.

L’adresse proposée au client ne choisit pas la confiance du serveur

Le champ token-authority peut suggérer au client une adresse où obtenir son jeton. C’est une indication facultative d’acquisition. La version 05 dit explicitement que le serveur l’ignore lorsqu’il contrôle la réponse au défi.

La preuve de l’émetteur passe par x5u ou x5c dans le jeton. L’un des deux doit être présent. Le serveur récupère ou lit le certificat, vérifie la signature, puis s’assure que sa configuration reconnaît ce certificat comme émetteur d’Authority Tokens pour l’écosystème concerné. Le simple fait de référencer un certificat ne lui confère donc aucune autorité.

L’origine de cette confiance n’est pas normalisée ici. Le projet laisse aux écosystèmes de déploiement leurs ancres et leurs exigences applicables aux certificats des Autorités de jetons ; la gouvernance STIR n’est citée qu’à titre d’exemple. Admission, portée, suspension et recours demeurent hors du texte.

Ce présupposé existait déjà dans RFC 9447, norme sur le défi Authority Token. Ce RFC suppose une relation préalable entre l’autorité de certification et l’Autorité de jetons, ainsi qu’entre le client et cette autorité. Là où ces relations ne peuvent être présumées, le mécanisme n’est pas applicable. Le nouveau profil affine le contenu autorisé ; il ne fabrique pas l’institution manquante.

Une validation réussie établit un faisceau de faits limité

Le serveur contrôle la structure et le type du jeton, sa signature, la présence et la validité temporelle de exp, ainsi que la présence de jti. Il vérifie le lien avec la clé du compte ACME qui a ouvert la commande et la concordance du drapeau ca avec le certificat demandé.

Il compare aussi exactement la contrainte contenue dans le jeton à celle de l’identifiant ACME. Si une étape échoue, le défi passe à l’état invalid et le serveur devrait renvoyer un document de problème ACME, généralement unauthorized. L’ensemble rend plus difficile l’emploi d’un jeton pour un autre compte, une autre forme de demande ou une autre séquence d’octets.

Ces garanties ne doivent pas être étirées. exp borne la fraîcheur, la signature rattache le message à une clé et l’égalité relie deux représentations. Rien dans ces opérations n’explique pourquoi l’émetteur figurait dans la configuration, quel mandat lui avait été délégué, quelle version de politique s’appliquait ou comment réparer une décision sémantique erronée.

La fiche Datatracker actuelle classe encore le projet In WG Last Call et indique seulement I-D Exists côté IESG. Elle ne nomme ni document shepherd ni Area Director responsable et ne fixe aucune téléconférence. L’appel initial annonçait une clôture au 25 juillet : le libellé actuel ne prouve donc pas que la période de commentaires reste ouverte. La révision 05 peut encore changer et n’est ni un RFC approuvé ni une preuve d’implémentation.

Deux détails préparent déjà l’exploitation. Une commande ne peut présenter qu’un identifiant JWTClaimConstraints et un identifiant TNAuthList. Le document recommande aussi de maintenir accessible l’URL x5u du certificat délivré tant que les parties utilisatrices peuvent en avoir besoin, normalement au moins jusqu’à l’expiration. Cette conservation aide à vérifier la signature, pas à retrouver l’origine institutionnelle de la confiance.

Un reçu d’autorité peut combler le vide sans exposer la demande

L’écosystème pourrait produire un reçu d’autorité sur la contrainte, relié à la décision ACME. Il associerait l’identifiant et la version de la politique, l’identité de l’Autorité de jetons et l’empreinte de son certificat fiable, la famille de contraintes et la classe de portée déléguée, ainsi qu’un condensat de la commande et de la contrainte.

Le reçu conserverait les heures d’émission, de décision et d’expiration, l’issue et une classe d’échec bornée, l’état d’entrée en vigueur ou de révocation de la confiance, et un contact pour incident, correction ou recours. Il préciserait que la validation technique n’est pas un verdict universel sur l’identité légale, la véracité d’un appel ou un droit extérieur à l’écosystème désigné.

Il s’agit d’une proposition éditoriale de Daniel Kade, non d’une exigence IETF. Elle ne requiert ni numéros de téléphone publics ni contenu brut de la contrainte. Le système réel de politique devrait émettre ce reçu automatiquement ; une seconde base remplie à la main ne ferait que déplacer l’opacité.