Résumé

  • Le paramètre facultatif token-authority aide le client à localiser un service. Il ne dit pas au serveur ACME quel émetteur croire : cette confiance vient d’une configuration d’écosystème et du certificat référencé par x5u ou x5c.
  • Le serveur transporte JWTClaimConstraints comme une chaîne opaque et confronte directement, octet par octet, la valeur de la commande à tkvalue, sans décodage, réencodage ni normalisation.
  • L’autorisation réunit des preuves distinctes : émetteur, signature, type, identité exacte, exp, jti, clé du compte ACME et rôle CA de la CSR. Le certificat émis et sa vérification JWS future restent deux faits ultérieurs.

Une indication de chemin, pas une délégation de confiance

Le nom token-authority invite à lui prêter trop de pouvoir. Dans le défi tkauth-01, sa fonction est pourtant précise : lorsqu’il est présent, le client ACME peut employer cette URL pour trouver l’autorité qui lui fournira le jeton JWTClaimConstraints. Lorsqu’il manque, le client doit connaître l’adresse par une configuration hors bande.

La révision 05 précise que le serveur ACME n’utilise pas ce paramètre pour valider la réponse. L’endroit où le client est envoyé ne devient donc pas, par simple contiguïté, une ancre de confiance. Le serveur accepte un signataire seulement si le certificat de celui-ci appartient à l’ensemble des émetteurs d’Authority Tokens que le déploiement lui a explicitement configuré pour l’écosystème concerné.

Le jeton présente ce certificat au moyen d’un lien HTTPS x5u ou d’une chaîne x5c. L’absence des deux, l’échec de récupération ou un certificat dépourvu du rôle configuré font échouer l’étape. Le champ facultatif iss peut nommer une autorité, mais un nom déclaré par le jeton n’accorde pas la confiance que le serveur doit établir lui-même.

Cette séparation permet de faire évoluer deux réalités indépendamment. Une URL de découverte peut changer pour des raisons de disponibilité. Un ensemble d’émetteurs peut changer à la suite d’une décision de gouvernance. Si le même réglage pilotait les deux, une opération de routage pourrait modifier silencieusement le périmètre d’autorisation.

Un objet sémantique pour l’un, des octets opaques pour l’autre

La valeur placée dans l’identifiant JWTClaimConstraints d’une nouvelle commande est l’encodage base64url sans remplissage d’un objet ASN.1 encodé en DER. Le jeton la reprend dans atc.tkvalue. Pour l’autorité de jetons, l’objet contient des contraintes STIR qu’elle doit confronter aux ressources et aux assertions que le demandeur est autorisé à représenter selon les RFC 8226 et 9118.

Le serveur ACME, lui, ne refait pas cette interprétation. La révision 05 lui demande de ne jamais analyser la structure interne. Son invariant est plus étroit et plus robuste : la chose signée par l’autorité doit être exactement celle que le client avait placée dans la commande d’origine.

Il ne s’agit pas d’une validation incomplète. C’est une attribution nette des responsabilités. L’acteur disposant du contexte STIR tranche le sens; le serveur ACME prouve le transport exact, l’émetteur, la signature, la durée, le compte et le rôle du certificat demandé.

Refuser l’équivalence fabriquée en chemin

DER et base64url sans remplissage imposent une forme canonique unique. La comparaison exigée est celle des deux chaînes reçues, octet par octet. Le serveur ne doit ni les décoder, ni les réencoder, ni les canoniser, ni les normaliser avant de décider qu’elles sont égales.

Un signe =, un caractère extérieur à l’alphabet base64url, un espace, un alphabet de remplacement, un BER qui n’est pas DER ou un seul octet différent entraînent l’échec. Le brouillon recommande aussi une comparaison en temps constant, mesure prudente même si les valeurs ne sont pas secrètes.

Chaque transformation permissive introduirait un nouvel arbitre : le code qui décide que deux écritures différentes « veulent dire la même chose ». Or cet arbitre se trouverait dans le chemin d’autorisation sans disposer du mandat sémantique de l’autorité de jetons. L’égalité exacte ferme cette surface et fournit un reçu simple : empreinte, longueur et résultat de comparaison de chaque valeur originale.

Décomposer le voyant vert

La procédure énumère huit contrôles. L’objet atc doit d’abord contenir tktype, tkvalue et fingerprint. Le certificat du signataire doit ensuite être reconnu comme émetteur autorisé, puis la signature doit être vérifiée. Le type doit être exactement JWTClaimConstraints. La valeur doit correspondre à celle de la commande d’origine.

exp doit exister et ne pas être dépassé selon l’horloge du serveur et sa faible tolérance locale; jti doit exister. L’empreinte signée doit correspondre à la clé du compte ACME qui présente la réponse. Enfin, le booléen ca doit correspondre au drapeau CA de Basic Constraints dans la demande de signature de certificat.

L’autorité de jetons ne vérifie pas elle-même que l’empreinte prouve le contrôle du compte. Elle la signe afin que le serveur ACME puisse effectuer cette jointure. Le rôle sémantique et le rôle de contrôle du compte contribuent ainsi deux preuves différentes.

Toute étape manquée invalide le défi et peut produire une erreur d’autorisation ACME. Regrouper ces échecs sous « jeton invalide » conserverait le verdict mais supprimerait la cause : confiance, récupération, signature, octets, horloge, transaction, compte ou rôle CA.

Le lien qui doit survivre à la commande

Une autorisation valide ouvre seulement la suite du flux d’émission. Le brouillon autorise en outre la CA à inclure un x5u facultatif dans la réponse de commande réussie. Le titulaire peut ensuite référencer ce certificat dans des objets JWS. La CA devrait maintenir l’URL accessible aussi longtemps que les parties vérificatrices en ont besoin, en général au moins jusqu’à l’expiration du certificat.

Ce lien postérieur n’est pas le x5u qui présentait le certificat de l’émetteur du jeton d’autorité. Les deux URL servent des étapes, des clés et des obligations temporelles différentes. Une émission réussie ne prouve pas que le certificat restera récupérable, qu’un tiers le validera, ni qu’une assertion téléphonique sera acceptée.

Limite des preuves disponibles

Le texte est un Internet-Draft de groupe de travail publié le 5 septembre 2026 et prévu pour expirer le 9 mars 2027. Il peut encore changer et ne constitue ni un RFC ni une preuve de déploiement. Ce dossier n’a testé aucun client, serveur, runtime, opérateur, dépôt de certificats ou parcours d’appel.

Les sources n’établissent aucune adoption, conformité, émission réussie, propriété de numéros, authentification d’appel ou réduction de fraude. Elles définissent un contrat proposé. Son exécution réclame des reçus issus des systèmes réels.

Sources