Résumé

  • Une adresse Onion v3 dérive de la clé publique d’identité du service, et non d’une délégation DNS ; joindre le service ne démontre donc pas à lui seul la maîtrise du nom.
  • Le défi onion-csr-01 fait signer par la clé Onion une CSR de validation fraîche, liée à deux nonces et distincte de la CSR finale du certificat.
  • La politique CAA peut rester dans le descripteur chiffré ou être présentée dans ACME sous forme signée et expirante, sans que l’une ou l’autre voie efface les risques de corrélation et de transparence.

Trois réussites, trois affirmations différentes

Supposons trois voyants au vert : le compte ACME signe correctement ses requêtes, le service répond via Tor, puis la CSR de finalisation passe les contrôles de forme. Aucun voyant n’est faux. Le problème naît lorsqu’ils sont additionnés pour produire une affirmation qu’aucun ne contient : « le demandeur contrôle l’identité Onion et l’AC est autorisée à émettre sans coût de confidentialité ».

Le nom .onion ne vient pas du DNS. RFC 7686 impose aux résolveurs et serveurs DNS ordinaires de ne pas lui inventer de résolution. Dans le format v3 de Tor, l’adresse encode la clé publique maîtresse Ed25519 du service, un contrôle d’intégrité et la version. Le nom est donc attaché à une clé. RFC 9799 conserve le type d’identifiant ACME dns pour l’interopérabilité, mais pas la chaîne de délégation qui accompagne un nom DNS classique.

Cette différence explique l’interdiction de dns-01. Elle explique aussi pourquoi http-01 et tls-alpn-01, bien qu’autorisés avec des adaptations, ne suffisent pas pour tous les besoins. L’AC doit établir elle-même la connexion Tor et ne peut déléguer la validation à Tor2Web. Ces méthodes attestent une réponse au point observé ; elles ne donnent pas de certificat générique et ne font pas parler directement la clé dont le nom est issu.

onion-csr-01 vise cette dernière preuve. L’AC fournit un nonce d’au moins 64 bits d’entropie. La réponse devient inacceptable si ce nonce a été créé plus de trente jours auparavant. Le client construit alors une CSR de validation contenant les octets bruts du nonce de l’AC dans caSigningNonce et son propre nonce, lui aussi d’au moins 64 bits, dans applicantSigningNonce. La clé privée du service Onion signe cette CSR.

L’AC vérifie la syntaxe PKCS#10, la correspondance entre la clé publique et le nom Onion, la signature, le nonce qu’elle a envoyé et l’entropie du nonce du demandeur. Le champ subject ne vaut pas identité et ne doit pas être validé. La clé publique de cette CSR doit en outre être différente de celle présentée lors de la finalisation.

La frontière est décisive. La clé du compte ACME autorise le dialogue avec le serveur. La clé d’identité Onion prouve le contrôle du nom. La clé finale sera celle du certificat et pourra suivre un cycle de rotation indépendant. Une seule clé qui jouerait les trois rôles simplifierait un diagramme, pas le risque. Le défi n’ajoute pas le key authorization habituel : la preuve arrive déjà dans une requête ACME signée par le compte.

L’AC ne voit la politique que si le service le décide

Un service en découverte restreinte chiffre son descripteur pour des clients autorisés. La visibilité n’est donc pas une conséquence automatique de la joignabilité. Le défi peut fournir authKey, la clé publique Ed25519 avec laquelle l’AC accédera au descripteur. Cette clé ne doit jamais être réutilisée entre deux services Onion ; elle peut l’être pour revalider le même service.

L’AC calcule son identifiant client et cherche l’entrée auth-client correspondante. Faute de correspondance, elle doit présumer que l’authentification client n’est pas requise. Si la clé est nouvelle, l’opérateur l’ajoute, signe de nouveau le descripteur et le republie. La propagation n’a pas de durée normative : le texte évoque quelques minutes, mais recommande au serveur de laisser au moins trente minutes avant expiration du défi.

La réponse du client à l’autorisation marque le moment où l’AC peut tenter de lire le descripteur. Elle ne prouve pas que la bonne révision s’est propagée. Une trace exploitable doit donc relier la clé annoncée, la révision publiée, l’identifiant client calculé, le premier déchiffrement réussi et le délai observé.

Une politique CAA sans parent DNS

RFC 9799 place les enregistrements CAA dans la seconde couche chiffrée du descripteur, avec la représentation canonique de RFC 8659. Ils continuent de dire quels émetteurs et méthodes sont permis. En revanche, aucune recherche ne remonte un arbre DNS et rien ne consulte un pseudo-TLD .onion. Tous les sous-domaines d’une même adresse Onion partagent la politique du service de base.

Une AC inconnue peut savoir qu’une politique existe sans pouvoir la lire. Le marqueur caa-critical, placé dans la première couche, impose alors l’arrêt jusqu’au déchiffrement et à l’analyse des CAA. Il révèle l’existence de la contrainte, non son contenu. Confondre ce marqueur avec une vérification achevée reviendrait à transformer un frein en laissez-passer.

La voie alternative transporte onionCAA dans la requête de finalisation. Pour chaque nom, l’objet contient les enregistrements ou null, une expiration Unix qui ne devrait pas dépasser huit heures, et une signature Ed25519 par la clé Onion. La chaîne signée est exacte : onion-caa|, l’expiration décimale sans zéro initial, un séparateur et le texte CAA ; null devient une chaîne vide.

Une signature valide établit l’origine et la fraîcheur de cette présentation. Elle n’établit pas le choix de l’AC. Celle-ci peut s’appuyer sur l’objet, l’ignorer et relire le descripteur, ou lire les deux. Un serveur incapable de récupérer le descripteur renvoie onionCAARequired si l’objet manque et peut annoncer inBandOnionCAARequired dans son annuaire. L’audit doit conserver la source réellement utilisée, son empreinte, son expiration et le résultat de politique.

La confidentialité n’est pas un sous-produit du certificat

Le chemin réseau laisse ses propres indices. Le serveur AC doit joindre lui-même le service via Tor. Le client ACME devrait lui aussi utiliser Tor et préférer un endpoint Onion de l’AC. Une connexion directe vers une adresse d’AC connue peut signaler qu’un service Onion existe sur l’hôte demandeur.

Une redirection http-01 vers le Web public peut révéler une adresse IP ou une proximité d’hébergement. L’AC ne doit alors pas valider ce domaine ordinaire via une sortie Tor, afin d’éviter le détournement de sortie. La mesure de confidentialité et la mesure d’intégrité ne pointent pas toujours dans la même direction.

Enfin, un certificat WebPKI publiquement approuvé rend le nom Onion visible dans les journaux de transparence des certificats. Cette publicité peut être le choix rationnel d’un service qui recherche la confiance des navigateurs ; elle peut être inadéquate pour un service interne. Le RFC conseille de réduire les données d’abonné et impose des clés de compte ACME séparées lorsque plusieurs services ne doivent pas être corrélés par l’AC.

Le dossier complet n’est donc jamais la seule chaîne de certificats. Il comprend la clé à l’origine du nom, le compte, la preuve fraîche, l’accès spécifique accordé à l’AC, la politique CAA effectivement lue, la clé finale et le registre des divulgations acceptées. Le standard coordonne ces passages. Il n’autorise pas le dernier artefact à réécrire l’histoire des précédents.

Sources