Summary

  • Un Internet-Draft individuel propose /.well-known/company-certs pour publier, via HTTPS, des ancres privées limitées à un usage applicatif, sans les verser dans le magasin de confiance global du système.
  • La preuve d’origine, la validité d’une chaîne et la sélection de l’entrée la plus récente ne prouvent pas que l’équipe compétente a autorisé le remplacement. Pendant un chevauchement, le choix du client peut changer alors que cette jonction reste invisible.
  • Daniel Kade propose un reçu de changement d’ancre : empreintes avant/après, époque exacte du document, périmètre, fenêtre de chevauchement, autorité d’approbation, politique locale, corroboration et retour arrière. Il s’agit d’une proposition éditoriale, non d’une exigence de l’IETF.

Un succès sans mandat visible

Il n’est pas nécessaire d’imaginer une compromission pour mettre le problème à nu. Une entreprise prépare une rotation normale. Elle publie l’ancienne chaîne et la nouvelle pendant quelques jours afin que les applications puissent basculer sans interruption. Les dates sont cohérentes, les domaines autorisés correspondent au certificat TLS du point d’accès et la nouvelle chaîne possède le valid_from le plus tardif.

Du point de vue du client, tout est propre. Le serveur est bien celui du nom demandé. Le JSON est lisible. Les certificats sont dans leur période de validité. La règle de choix produit une réponse déterministe. Pourtant, aucune de ces vérifications n’identifie l’acteur qui a approuvé la nouvelle ancre, le dossier de changement auquel elle appartient ni l’application exacte à laquelle l’autorisation s’étend.

Cette différence n’est pas administrative. Une ancre de confiance est une entrée du raisonnement de validation. Dès que l’application l’accepte, des chemins de certification auparavant inacceptables peuvent devenir valables dans le contexte prévu. La capacité de modifier le document publié est donc une capacité de modifier le périmètre d’autorité reconnu par le logiciel.

La proposition technique, sans lui prêter davantage

draft-doehle-company-certs-discovery-00 est un Internet-Draft individuel daté du 22 juillet 2026. Il vise la voie Standards Track, mais sa seule révision est -00 au moment de cette analyse. Ce n’est ni un RFC, ni un constat de déploiement, ni une décision de l’IETF.

Le mécanisme place un objet JSON versionné sous /.well-known/company-certs. Il décrit des informations d’autorité et des ancres associées à un usage_context. Chaque ancre peut comporter plusieurs chaînes avec une période de validité, une URL HTTPS de même origine, une chaîne X.509 en PEM, des indications CRL ou OCSP et une empreinte SHA-256. Le document peut encore restreindre les domaines permis et demander un magasin isolé.

L’ambition est justement de ne pas contaminer la confiance globale. L’application découvre ce dont elle a besoin pour un échange privé précis ; elle ne transforme pas pour autant cette autorité en racine universelle du système d’exploitation. Le projet ne remplace pas la Web PKI, ne délivre pas de certificats d’extrémité et ne certifie pas la qualité générale d’une AC privée.

Les contraintes d’origine sont sérieuses. HTTPS doit être vérifié. L’URL de la chaîne reste de même origine. Un domaine permis doit être identique à un identifiant DNS du certificat de l’endpoint ou se trouver sous celui-ci. Ces règles empêchent un domaine de publier sans limite des ancres pour des espaces qui ne lui appartiennent pas.

Elles ne décrivent pas pour autant la constitution interne de l’organisation. Le détenteur de la capacité de publier peut être une chaîne de déploiement web, une équipe de plateforme, un prestataire de diffusion ou un compte de service. L’autorité compétente pour approuver une rotation peut se trouver ailleurs.

L’origine et l’organisation ne sont pas le même sujet

RFC 8615 organise l’espace des URI « well-known ». Son analyse de sécurité souligne qu’un droit d’écriture sur une telle ressource peut valoir pouvoir sur toute l’origine. Cette observation est particulièrement importante dans un hébergement partagé ou lorsque plusieurs équipes disposent de chemins de publication différents.

Le contrôle du domaine est une preuve utile : il situe l’énoncé et borne l’espace de noms. Il ne faut pas l’affaiblir en exigeant qu’il prouve autre chose. Il ne dit pas si le responsable PKI a validé la chaîne, si le propriétaire de l’application a accepté le nouveau périmètre, si une procédure de double contrôle était requise ou si l’exception d’urgence est déjà arrivée à échéance.

RFC 9525 aide le client à vérifier qu’une identité TLS correspond au nom de référence voulu. Là encore, la vérification établit une relation entre un nom et un serveur présenté. Elle n’est pas un procès-verbal de comité de changement. Un endpoint peut être parfaitement authentique et servir une modification dont le mandat interne n’est pas démontrable.

Même une automatisation légitime a besoin d’un mandat borné. « Le pipeline l’a publié » décrit l’exécution. Pour décrire l’autorité, il faut aussi savoir quels usages ce pipeline peut modifier, quelles empreintes il peut substituer, quelle seconde preuve il doit attendre, combien de temps le chevauchement peut durer et qui peut interrompre le mouvement.

valid_from ordonne, il n’approuve pas

Quand plusieurs chaînes conviennent au même usage, le projet prévoit d’ignorer celles qui sont hors période et de retenir la chaîne applicable dont le valid_from est le plus récent, sauf politique locale contraire. Cette règle évite un choix arbitraire. Son verbe est « sélectionner », pas « autoriser ».

RFC 3339 facilite l’écriture de dates interopérables. Une date peut prouver l’ordre revendiqué par le document ; elle ne prouve ni l’auteur de la décision, ni la raison du chevauchement, ni l’accord de deux équipes. Une valeur plus tardive peut être correctement formatée dans une publication légitime, erronée ou hostile.

RFC 5280 ne referme pas ce vide. La validation d’un chemin utilise les ancres et les politiques fournies localement. Elle peut confirmer que le nouveau chemin est mathématiquement et sémantiquement acceptable selon ces entrées. Elle ne certifie pas le processus qui a introduit l’ancre parmi les entrées.

Il serait donc faux de conclure que la règle du plus récent est faible. Elle accomplit exactement son travail. L’erreur commence lorsque le tableau de bord transforme « chaîne sélectionnée conformément à la politique » en « rotation approuvée par l’organisation ».

L’isolement est une obligation d’exécution

Le champ isolated_store_required exprime l’intention de l’éditeur. Le projet précise qu’il ne constitue pas une barrière technique. Un client qui ne peut pas isoler l’ancre devrait la refuser plutôt que l’insérer discrètement dans un magasin plus large.

Cette formulation distribue correctement les responsabilités. L’éditeur demande un périmètre ; le client doit savoir s’il est capable de le produire. Le contrôle ne peut pas s’arrêter à la présence du booléen. Il faut observer dans quel magasin l’ancre a été chargée, quels appels de validation peuvent la consulter et si une bibliothèque commune élargit sa portée.

Les permitted_domains posent la même question côté exécution. Leur présence dans le JSON n’empêche pas un parseur d’ignorer le champ, un cache de mélanger deux usages ou une refonte de déplacer l’ancre vers une collection commune. Le reçu de gouvernance doit relier la restriction déclarée au comportement réel du client.

L’isolement est la promesse de sécurité la plus originale du dispositif. S’il disparaît, une commodité limitée à une application peut devenir une décision de confiance bien plus vaste. Cette extension doit être détectée comme une modification d’autorité, non comme un simple détail d’implémentation.

Une réponse fraîche peut porter une autorité périmée

RFC 9110 et RFC 9111 séparent la sémantique HTTP, la fraîcheur du cache et la revalidation. Le projet recommande une mise en cache prudente, des revalidations périodiques et une résistance au rejeu ; le client peut imposer sa propre durée maximale.

Ces mesures indiquent si la représentation de l’origine est assez récente. Elles ne renouvellent pas automatiquement la décision interne. Une approbation d’urgence peut expirer avant le cache. L’équipe de sécurité peut retirer son accord alors qu’un point de diffusion sert encore l’époque précédente. Inversement, un nouvel objet peut être frais tout en n’ayant jamais reçu le visa du propriétaire de l’application.

La première récupération réussie est un événement à part. Avant elle, aucune ancre de ce canal n’est disponible. Après elle, de nouveaux chemins peuvent être acceptés. Le projet lui-même qualifie ce bootstrap de sensible. Les opérations doivent donc distinguer l’enrôlement initial, l’actualisation routinière, le chevauchement, la bascule, le retrait et le retour arrière.

La fréquence des requêtes a aussi un coût de confidentialité : elle peut révéler l’intérêt pour une organisation ou un usage. Un cache raisonnable protège cette information, mais son horizon devient alors un élément de la décision de confiance. Il doit être calibré sur le délai acceptable de correction, pas seulement sur le confort du transport.

Le statut d’un certificat n’est pas le statut de la décision

Des pointeurs CRL et OCSP peuvent accompagner les chaînes. RFC 6960 permet d’interroger le statut d’un certificat. C’est indispensable dans de nombreux cycles de vie, mais cela ne répond pas à la question de la rotation de l’ancre.

Une AC nouvellement publiée peut émettre des certificats non révoqués alors que sa mise en confiance n’a pas été correctement autorisée. Une ancienne ancre peut rester valide alors que l’organisation voulait la retirer. Le statut des certificats subordonnés ne reconstruit ni la décision, ni le périmètre, ni la période pendant laquelle deux bases de confiance ont coexisté.

Supprimer l’entrée du serveur ne corrige pas instantanément tous les clients. Certains disposent d’un cache, certains sont hors ligne, certains maintiennent des sessions, d’autres ont copié l’ancre ailleurs. La correction doit identifier les populations, la date limite de propagation et la preuve que l’ancre n’a pas quitté son magasin isolé.

Le reçu de changement d’ancre

Je propose un reçu de changement d’ancre de confiance. Ce reçu n’est ni un champ imposé au JSON public, ni une prescription de l’IETF. C’est la jonction opérationnelle qui permet de ne pas confondre publication authentifiée et mandat complet.

Il fige d’abord l’époque : empreinte du document, origine, identité de référence validée, instant de récupération et état du cache. Il ajoute le contexte d’usage, les domaines permis et l’exigence d’isolement. Une autorisation donnée pour ce digest ne peut ainsi s’étendre au contenu que l’endpoint publiera plus tard.

Il nomme ensuite le mouvement : empreintes des anciennes et nouvelles ancres, identifiants des chaînes, valid_from, valid_until, fenêtre de chevauchement et état de bascule prévu. Une addition, un remplacement, un retrait et un retour d’urgence sont des actes différents, même si chacun produit un JSON syntaxiquement valable.

La partie « autorité » indique le rôle, la politique ou l’automate borné qui a approuvé l’acte, ainsi qu’une référence protégée au dossier correspondant. Il n’est pas nécessaire de publier le nom d’une personne ou des débats internes. Il faut en revanche pouvoir vérifier le mandat par un canal indépendant de celui qui a exécuté la publication.

La partie locale consigne la décision du client : règle du plus récent ou dérogation, corroboration demandée, capacité d’isolement, échéance de revalidation et conduite en cas d’indisponibilité. Enfin, le reçu inclut les chemins de correction, les classes de clients touchées, le délai maximal de retrait et sa propre expiration.

Une seconde preuve proportionnée

Toutes les applications ne justifient pas un double contrôle solennel. Un outil de test aux droits limités peut se satisfaire d’une approbation de dépôt liée à l’origine. Un service de signature, de paiement ou de contrôle d’infrastructure peut exiger une clé d’approbation distincte ou un registre de changement protégé.

L’indépendance ne se résume pas à deux messages. Une deuxième URL servie par la même chaîne ou une notification envoyée par le même compte n’ajoute guère de séparation. La corroboration peut provenir d’un système PKI, d’un manifeste signé, d’un journal protégé, d’une clé matérielle ou d’un autre domaine administratif.

RFC 5011 offre seulement une comparaison prudente. Dans le contexte des mises à jour automatiques d’ancres DNSSEC, il distingue des états d’ajout, d’attente et de retrait. Il ne régit pas Company-Certs. Il montre néanmoins qu’un logiciel autorisé à modifier sa propre base de confiance mérite un état de transition durable, pas uniquement une valeur « courante ».

Préserver les verbes

Le projet de spécification trace une frontière utile. Il formalise une distribution HTTPS, bornée par le domaine et l’application, qui vaut mieux qu’un fichier d’AC transmis sans contexte ou qu’une installation silencieuse dans le magasin global. On ne devrait pas lui demander de reproduire toute la gouvernance d’une entreprise.

La bonne couche suivante consiste à garder les verbes séparés. HTTPS authentifie une récupération. JSON représente un état. La validation X.509 teste un chemin avec des entrées locales. La politique du client choisit une chaîne. L’organisation autorise une modification. Le reçu joint ces faits sans laisser le premier parler au nom de tous les autres.

Les sources ne démontrent aucun déploiement, incident ou abus nommé. Le scénario d’ouverture est un test de conception fondé sur la règle de coexistence du projet. Son enseignement est plus calme et plus exigeant : un point d’accès peut publier une nouvelle confiance, mais seule une preuve distincte peut dire qui lui a donné le droit de changer ce que l’application croit.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-doehle-company-certs-discovery-00
  5. https://datatracker.ietf.org/doc/draft-doehle-company-certs-discovery/
  6. https://datatracker.ietf.org/doc/draft-doehle-company-certs-discovery/history/
  7. https://www.rfc-editor.org/rfc/rfc8615.html
  8. https://www.rfc-editor.org/rfc/rfc9525.html
  9. https://www.rfc-editor.org/rfc/rfc5280.html
  10. https://www.rfc-editor.org/rfc/rfc6960.html
  11. https://www.rfc-editor.org/rfc/rfc9110.html
  12. https://www.rfc-editor.org/rfc/rfc9111.html
  13. https://www.rfc-editor.org/rfc/rfc8259.html
  14. https://www.rfc-editor.org/rfc/rfc3339.html
  15. https://www.rfc-editor.org/rfc/rfc5011.html