Résumé

  • Un paramètre accounturi reconnu limite une propriété CAA au compte demandé, tandis que validationmethods la limite aux méthodes reconnues ; ni l’un ni l’autre ne remplace la concordance avec le domaine identifiant de l’AC.
  • La reconnaissance est facultative et propre à l’AC. En revanche, une fois annoncée pour un domaine identifiant, elle doit rester cohérente dans tous les systèmes d’émission qui emploient ce domaine.
  • Une autre propriété CAA applicable et plus permissive peut autoriser la même AC ; le resserrement ultérieur du DNS ne révoque pas les certificats déjà émis.

La difficulté d’une intégration d’émetteurs n’apparaît pas nécessairement dans l’infrastructure la plus récente. Elle se cache souvent dans la porte que personne ne veut encore fermer : un service d’entreprise ancien, une interface non-ACME ou un produit géré dont les comptes portent un autre format. Les trois portes peuvent afficher le même domaine d’AC dans CAA. Ce partage rend leurs différences de politique juridiquement invisibles pour le protocole, mais pas techniquement inoffensives.

RFC 8659 définit CAA comme une autorisation d’émettre, pas comme une règle de validation côté navigateur. Pour chaque nom demandé, l’AC recherche le RRset pertinent, suit les alias lors de la requête CAA et remonte les noms jusqu’au premier ensemble non vide. Le résultat décrit l’autorité présente. Il n’annule pas rétroactivement un certificat existant.

RFC 8657 permet de rendre cette autorité plus précise. accounturi rattache la propriété issue ou issuewild qui le contient au compte identifié par l’URI de la demande. Le domaine identifiant de l’AC doit toujours correspondre. Sans paramètre, tout compte peut satisfaire cette propriété. Plusieurs valeurs, une URI invalide ou non reconnue rendent la propriété impropre à autoriser la demande.

L’URI de compte est publique. Ce n’est ni le secret du compte ni une autorisation transportable. Une implémentation ACME qui prend en charge l’extension reconnaît l’URI de l’objet compte ACME ; un système non-ACME peut définir une autre URI. Copier l’identifiant ne confère donc aucun contrôle sur les justificatifs du compte.

validationmethods agit sur un autre axe. Sa liste séparée par des virgules limite l’autorisation aux méthodes nommées ; une liste vide n’en autorise aucune. Les libellés ACME sont enregistrés, alors qu’une méthode non-ACME peut demander un nom propre à l’AC. La chaîne publiée dans le DNS n’est opérante que si l’émetteur affirme la reconnaître.

Cette affirmation ne se déduit pas de la syntaxe. RFC 8657 rend la reconnaissance facultative et spécifique à chaque AC, et recommande une documentation explicite. Let's Encrypt documente ainsi le domaine letsencrypt.org, la forme de ses URI de compte et les méthodes http-01, dns-01 et tls-alpn-01. Cette page est une déclaration publique bornée ; elle ne constitue ni audit indépendant ni preuve d’adoption générale.

La contrainte la plus forte vise l’organisation de l’émetteur. Tous les systèmes qui utilisent un même domaine identifiant d’AC doivent reconnaître les paramètres de façon cohérente. Le RFC cite expressément la coexistence de systèmes ACME et non-ACME, ainsi que les rapprochements d’entreprises. Une AC incapable d’aligner les interprétations peut employer des domaines identifiants séparés. Elle ne doit pas annoncer la prise en charge sous un domaine commun si une porte conserve un autre sens.

L’unification des comptes n’est pas imposée entre AC sans rapport. Pour une même AC, les URI doivent toutefois rester non ambiguës dans tous les domaines identifiants qu’elle reconnaît, y compris après fusion de deux espaces de noms. Une composante d’autorité dans l’URI réduit le risque que deux anciens « comptes 1042 » deviennent un seul identifiant apparent.

La politique DNS elle-même peut ouvrir une issue latérale. Les autorisations CAA s’additionnent. Une ligne restrictive n’annule pas une autre ligne applicable qui autorise la même AC sans compte ou méthode. Pour un joker, issuewild l’emporte lorsqu’il existe et issue est alors ignoré ; pour un nom ordinaire, c’est issue qui reste pertinent.

Le drapeau critique ne transforme pas les paramètres en obligation universelle. Il règle le cas d’un tag de propriété inconnu ou non pris en charge. Placé sur issue, il n’impose pas la compréhension de chaque paramètre de cette propriété. Confondre le tag et ses paramètres produit une assurance fictive.

Enfin, l’autorisation de domaine et l’émission peuvent être séparées dans le temps. Des autorisations plus courtes ou une nouvelle vérification CAA près de l’émission réduisent cet intervalle ; l’ordre de grandeur d’une heure évoqué par le RFC reste illustratif. Une période permissive peut donc produire des certificats qui restent valides après son terme.

La preuve recherchée n’est pas « l’AC est autorisée ». Elle doit dire quel RRset a été obtenu, pour quel nom, par quel chemin DNS, quelle propriété s’appliquait, quel domaine d’AC a concordé, quels compte et méthode ont été reconnus, par quel système, à quel instant, puis quel certificat a été émis.

Sources

  1. RFC 8657 — Extensions CAA pour l’URI de compte et la liaison de méthode ACME
  2. RFC 8659 — Enregistrement DNS Certification Authority Authorization
  3. Let's Encrypt — Documentation CAA
  4. Heng Lu — Le problème d’agence au cœur de la gouvernance de l’Internet
  5. Heng Lu — Pourquoi BTW Media existe et pourquoi la réalité est le produit