Résumé

  • La politique Mozilla distingue le maintien d’un magasin de racines et l’assurance périodique des pratiques de validation nécessaires avant l’inclusion d’informations dans un certificat.
  • Une règle ou un audit couvrant une période ne reconstitue ni une demande donnée, ni une observation de validation, ni une émission, ni un état de révocation ultérieur, ni le résultat d’un client.

La version 3.1 de la Mozilla Root Store Policy, applicable depuis le 1er juillet 2026, juxtapose utilement plusieurs réalités sans les confondre. Mozilla distribue des certificats d’AC assortis de bits de confiance selon l’usage. La politique exige certains audits avant l’inclusion puis au moins chaque année pour les racines et intermédiaires techniquement capables qui entrent dans son champ. Elle exige aussi que l’AC vérifie, avant de l’inscrire dans un certificat, une information fournie par un souscripteur au moyen d’une source indépendante ou d’un canal distinct.

Pour un certificat TLS, l’AC doit s’assurer de l’autorisation sur les noms de domaine et du contrôle des adresses IP par les méthodes documentées.

Ces phrases sont toutes importantes. Aucune ne se transforme automatiquement en la suivante.

Un audit porte sur une frontière d’assurance. Il comporte un système couvert, des critères, une période, des méthodes, des éléments testés, des conclusions et des limites. La politique prévoit des informations d’audit de période mises à jour au moins annuellement. Pour les périodes annuelles commençant le 1er juillet 2027 ou après, elle prévoit aussi un Detailed Controls Report pour certaines AC ayant le bit de confiance web. Ce rapport doit éclairer les frontières du système, les contrôles, leur mise en œuvre, les tests et leur efficacité.

C’est un élément de gouvernance substantiel; ce n’est pas l’archive exhaustive des demandes de certificats ni la preuve contemporaine d’une émission précise.

La différence apparaît dès qu’on regarde un certificat. Son numéro de série, son émetteur, sa durée de validité et ses noms alternatifs décrivent un objet. Ils ne disent pas quelle demande fut reçue, quelle version de procédure s’appliquait, qui ou quel système était habilité, quelle source indépendante a été consultée, si l’observation restait dans sa fenêtre admissible, ou pourquoi une clé fut liée à ces noms. Une opinion d’audit ne crée pas ces liaisons manquantes par le seul fait qu’elle existe.

L’inverse est tout aussi risqué. Une trace d’émission peut établir qu’un objet a été créé. Elle ne prouve pas que l’environnement de contrôle entier a fonctionné pendant une période, que tous les sites étaient couverts, qu’aucun fait ultérieur n’existe, ou que tous les logiciels dérivés ont gardé le même traitement de racine. La politique Mozilla précise que les distributeurs de logiciels fondés sur les siens peuvent ajouter, retirer ou modifier les certificats et bits de confiance. La politique concerne donc une distribution par défaut de Mozilla, non toutes les distributions possibles.

L’émission n’est pas non plus l’acceptation ultérieure. La documentation NSS distingue les blocs de certificat et les blocs de confiance; une racine est le certificat plus ses réglages de confiance. Un client doit encore évaluer une chaîne avec son logiciel et son contexte. Le nom d’hôte, le temps, les extensions, la construction de chaîne, la révocation, l’usage applicatif et le service observé au moment de la connexion sont d’autres questions. Ceci ne décrit l’échec d’aucun client; cela délimite ce qu’un audit ou un dossier d’émission peut démontrer sans preuve côté client.

La réponse pratique est un reçu d’émission borné. Il devrait conserver sous protection un identifiant de demande; les noms demandés et l’empreinte de la clé; la version de procédure; l’acteur autorisé ou le contrôle automatisé; l’observation indépendante et sa fenêtre temporelle; puis le numéro de série, l’émetteur, la validité, les extensions pertinentes et l’instant d’émission. La révocation ultérieure doit être conservée séparément, avec l’instant de consultation et le contexte de réponse.

Le résultat du client doit l’être encore séparément, avec version du client, nom d’hôte, chaîne et heure, sans accumuler de données inutiles sur l’utilisateur.

Il ne s’agit pas de publier des preuves de contrôle de domaine, des dossiers clients ou des détails de sécurité. Il s’agit d’empêcher qu’une affirmation devienne le substitut d’une autre. Les éléments sensibles peuvent être examinés sous autorité appropriée. La carte des liaisons, elle, doit rester durable : quelle décision a soutenu quel objet, selon quelle règle, et quelle observation ultérieure est réellement invoquée.

Limites des preuves

Les sources étudiées ne désignent ni AC, ni souscripteur, ni certificat, ni opinion d’audit, ni DCR, ni incident, ni événement côté tiers de confiance. Elles n’établissent aucune défaillance. Le reçu proposé est une analyse éditoriale, pas une exigence Mozilla, CA/Browser Forum, NSS ou RFC.

Sources

  1. Mozilla Root Store Policy 3.1
  2. Mozilla NSS : Updating NSS’s Root Store
  3. RFC 5280