Résumé

  • La révision 06 de draft-ietf-tls-trust-anchor-ids propose des identifiants courts pour aider le serveur à choisir un chemin de certificats ; la liste annoncée n’est ni exhaustive ni contraignante pour la politique de confiance du client.
  • Un groupe peut contenir des ancres refusées localement. Une sélection conforme peut donc échouer à la validation ; une liste envoyée par le serveur permet alors, au plus, une nouvelle connexion ciblant une ancre individuelle.
  • La gouvernance doit séparer le signal, l’inventaire des chemins, le choix et le repli, la validation, la reprise, la confidentialité et le résultat observé.

La compression paraît d’abord être une affaire de protocole. Un nom distinctif de certification peut être long ; une collection complète d’autorités acceptables peut gonfler le ClientHello. Le projet du groupe de travail TLS remplace cette énumération, dans certains cas, par de courts Trust Anchor IDs. Un identifiant individuel désigne une ancre ; un motif de groupe représente plusieurs ancres. Le serveur peut alors choisir, parmi ses chaînes disponibles, celle qui semble convenir au client.

Mais la compression déplace une partie du coût hors du paquet. Pour qu’un groupe soit utile, le client et le serveur doivent comprendre sa composition de manière compatible. Et même s’ils s’accordent parfaitement sur cette composition, ils ne sont pas tenus d’accorder la même confiance à chacun de ses membres.

La révision 06 a été mise à jour le 30 septembre 2026. Son en-tête indique « Standards Track » comme statut visé. Dans l’enregistrement Datatracker figé pour cette analyse, intended_std_level et std_level restent nuls. Le texte est un Internet-Draft, non un RFC. Rien dans le corpus retenu ne prouve un déploiement, une adoption ou une interopérabilité en production.

Une indication volontairement incomplète

Le client construit une RequestedTrustAnchorList non ordonnée dans le ClientHello ou dans CertificateRequest. Cette liste peut être vide. Surtout, le projet l’autorise à ne pas refléter fidèlement le magasin de confiance : il peut omettre une ancre pourtant approuvée, annoncer une ancre non approuvée ou employer un groupe dont certains membres seraient refusés. La taille du message et la réduction du pistage sont des raisons possibles de cette imprécision.

Il faut donc lire le signal comme une demande de sélection, non comme une délégation d’autorité. Le serveur inventorie ses chemins candidats. Pour chacun, il conserve l’identifiant de l’ancre émettrice et les motifs de groupe correspondants. Il compare cet inventaire aux identifiants reçus. S’il trouve une correspondance, il devrait envoyer le chemin associé. Si l’extension certificate_authorities est également présente, le projet permet de satisfaire l’une ou l’autre indication. Sans correspondance, le serveur peut interrompre la négociation ou présenter un certificat de repli.

À ce stade, rien n’est encore « digne de confiance ». Le client doit toujours vérifier le chemin selon sa politique : ancre réellement autorisée, identité applicative, périodes de validité, contraintes, algorithmes et règles locales. Une mauvaise annotation côté serveur peut provoquer une panne reproductible. Une liste volontairement large peut provoquer exactement la même panne. Aucune des deux n’ajoute l’ancre au magasin de confiance.

Cette propriété protège l’autorité locale, mais elle transforme une incohérence de métadonnées en risque de disponibilité. Le groupe n’est donc pas seulement un objet de normalisation. Sa composition, sa version, sa diffusion et son retrait deviennent des contrôles d’exploitation.

Le chemin strict ne dispense pas de juger

Lorsqu’un certificat correspond à l’identifiant demandé, le serveur peut inclure une extension trust_anchors vide dans son message Certificate. Ce marqueur impose une liste de certificats complète, correctement ordonnée et sans élément superflu. Le client peut alors traiter la liste comme un chemin déjà construit au lieu de chercher lui-même une route possible dans un graphe de certificats.

RFC 4158 décrit les difficultés de construction d’un chemin ; RFC 5280 encadre sa validation. Le projet simplifie potentiellement la construction. Il n’abolit pas la validation. Une chaîne bien rangée peut encore être expirée, contraire à une contrainte de nom, signée par un algorithme interdit ou terminée par une ancre absente de la politique locale.

La télémétrie doit préserver cette séparation. « Correspondance avec l’identifiant demandé » est une preuve de sélection. « Chemin validé par la politique P » est une preuve d’acceptation. Un seul voyant vert masque le point exact où la coordination a échoué.

Une deuxième connexion pour corriger le choix

Le projet prévoit un mécanisme de reprise. Dans EncryptedExtensions, le serveur peut envoyer une liste non vide d’identifiants d’ancres individuelles disponibles, ordonnée selon ses préférences. Si le client rejette ensuite le certificat présenté, il recherche dans cette liste une ancre qu’il accepte réellement. Il peut concilier la préférence du serveur avec la sienne, puis ouvrir une nouvelle connexion en ne demandant que cet identifiant individuel.

Cette reprise est limitée à une tentative. Sans liste, sans intersection de confiance ou après un nouvel échec, l’application reçoit une erreur. La reprise ajoute aussi un aller-retour. Elle ne répare pas la politique ; elle corrige la supposition qui a conduit au mauvais chemin.

Pour un changement d’autorité, cette nuance est décisive. Un opérateur peut présenter en priorité une chaîne vers une nouvelle racine et conserver une chaîne plus répandue comme solution de repli. Les clients prêts avancent directement ; d’autres paient une nouvelle connexion. Le coût apparaît dans la latence de queue et dans les échecs visibles. Il doit être attribué à un propriétaire, pas dissous dans une moyenne de succès TLS.

La confidentialité n’est pas proportionnelle à la longueur

Le texte distingue les clients qui n’envoient jamais la liste, ceux qui l’envoient sous condition et ceux qui l’envoient systématiquement. Une émission conditionnelle exige en général une sonde active pour être observée. Une émission inconditionnelle se collecte passivement. Une liste propre à un utilisateur devient alors une empreinte, même si chaque identifiant est court.

Le projet déconseille une liste inconditionnelle unique et préfère une liste commune à un ensemble d’anonymat. L’historique peut néanmoins réapparaître : une liste construite d’après des connexions précédentes peut relier plusieurs sessions. Côté serveur, la liste des ancres disponibles doit être filtrée pour le service demandé, notamment selon le SNI. Exposer tous les chemins d’une plateforme partagée révèle une topologie institutionnelle inutile.

Un groupe élargit parfois l’ensemble d’anonymat, mais il ne suffit pas à produire de la confidentialité. Il faut connaître la population qui utilise ce groupe, la stabilité du signal, les conditions d’émission et les états antérieurs qui ont contribué à sa construction.

Un reçu au lieu d’une autorité centrale

Une mise en œuvre conforme au principe du minimum initial n’a pas besoin d’une autorité mondiale décidant quelles ancres chaque client doit accepter. Elle a besoin d’un reçu local, comparable et inspectable.

Ce reçu porte sept éléments. Il conserve d’abord la politique de signal : identifiants individuels et groupes, émission conditionnelle ou non, règle de confidentialité. Il décrit ensuite l’inventaire des chemins du serveur et la provenance de leurs métadonnées. Il note le choix et le repli : extension ayant produit la correspondance, ordre de préférence, comportement sans résultat.

Il maintient séparément la validation locale, avec la version du magasin et la raison exacte d’acceptation ou de refus. Il trace la reprise, y compris la liste disponible, la tentative unique et son coût. Il documente le mode de confidentialité et le filtrage par service. Enfin, il consigne le résultat : chemin servi, issue du handshake, motif d’échec et conséquence applicative.

Le choix d’un certificat par le serveur ne constitue pas une approbation de l’autorité qui l’a émis. L’annonce d’un groupe par le client n’est pas un vote en faveur de chaque membre. Ces événements montrent seulement comment deux systèmes indépendants ont tenté de coordonner une sélection.

Sources