Résumé

  • La pull request 622 reste un Draft Ballot SC-XX ouvert. Aucun numéro définitif, vote, examen IPR, texte adopté ou entrée en vigueur n’est établi au 2 septembre 2026.
  • Les TLS Baseline Requirements en vigueur font courir le délai jusqu’à la révocation publiée à compter de la réception d’un Certificate Problem Report. Le projet intercalerait une décision d’« actionnabilité » prise par l’AC dans les 24 heures, puis ferait partir le délai de révocation applicable de cette décision.
  • Actionable désigne un seuil d’entrée, non la preuve d’un manquement. Le texte gelé demande au moins un identifiant valable d’un certificat encore valide et non révoqué, ainsi qu’une violation décrite ou un motif de révocation.
  • Cette même date de qualification ouvrirait un délai de 120 heures pour examiner les autres certificats valides et non révoqués émis par l’AC. Le délai de chaque certificat supplémentaire partirait de sa première identification.
  • La définition proposée de Revoked exige un résultat observable aux URI CRL et OCSP applicables. Elle dépasse donc un indicateur interne, sans garantir que tous les caches voient le changement au même instant.
  • Un reçu limité peut relier réception officielle, qualification, constat de fond, extension de la population, échéance et publication, tout en protégeant clés compromises, contenu du signalement et données d’abonnés.

L’événement le plus important n’est pas forcément la révocation

Quand un certificat est finalement marqué révoqué dans une CRL ou par OCSP, le résultat se prête à un test. On peut interroger l’adresse indiquée dans le certificat et conserver la réponse. Le début du parcours est moins net. Un signalement entre par un formulaire ou une adresse ; quelqu’un doit décider s’il contient assez d’éléments pour engager la procédure.

La pull request 622 transforme cette décision en seuil temporel. Après réception, l’AC disposerait de 24 heures pour dire si le Certificate Problem Report est actionable. Une qualification positive ouvrirait plusieurs chemins : réponse au déclarant joignable dans les 24 heures, délai de révocation correspondant au motif invoqué, et examen de toute la population des certificats valides et non révoqués dans les 120 heures.

Les délais de la section 4.9.1.1 ne sont pas identiques. Une compromission de clé privée ou une validation de domaine devenue indigne de confiance appelle une révocation dans les 24 heures. D’autres causes portent une recommandation de 24 heures et une obligation de cinq jours. Le reçu doit donc indiquer à la fois le point de départ et la classe de motif ; « traité à temps » ne signifie rien sans ces deux données.

La version 2.2.9 en vigueur rattache encore l’intervalle extérieur à la réception du signalement ou de l’avis relatif à la révocation. Le projet le rattache à la qualification. Il ne cache pas l’effet : sa justification présente cette fenêtre comme le temps nécessaire pour vérifier que le signalement est exploitable avant de soumettre l’AC au délai principal.

Cette respiration peut éviter qu’une accusation sans certificat ni explication lance un compte à rebours sévère. Elle crée aussi une responsabilité nouvelle. La qualification n’est plus un simple tri de boîte aux lettres ; elle détermine la date de conformité.

Recevable ne veut pas dire fondé

La meilleure lecture du seuil proposé est syntaxique et opérationnelle. Il faut un identifiant valable d’au moins un certificat émis par l’AC, encore dans sa période de validité et non révoqué. Le numéro de série doit être accepté ; l’empreinte SHA-256 du certificat ou du précertificat devrait l’être. Il faut ensuite expliquer quelle règle ou politique aurait été violée, ou exposer un motif de révocation.

Le déclarant ne gagne pas pour autant. Une analyse peut satisfaire toutes ces conditions et reposer sur une interprétation erronée. L’AC peut conclure qu’aucun manquement n’existe. Inversement, elle ne devrait pas repousser le délai jusqu’au moment où elle accepte le fond du dossier. Les commentaires publics insistent sur cette différence : reconnaître qu’un dossier est exploitable n’est ni constater la non-conformité ni achever les remèdes.

Le canal officiel forme une autre partie du test. Le projet exige des instructions dans la section 1.5.2 du CPS et recommande une page ou une FAQ aisément accessible. Il autorise des contrôles qui bloquent les soumissions non exploitables, tout en exigeant que les signalements exploitables puissent entrer.

La discussion a montré pourquoi une formule générale serait dangereuse. Un salarié quelconque ne peut pas devenir responsable d’un délai de 24 heures parce qu’une clé lui a été envoyée directement. Mais un formulaire qui refuse la seule preuve utilisable n’est pas davantage un canal réel. Le reçu doit identifier le point d’entrée, la version des instructions publiques et la réponse technique qui atteste la réception.

La fin sort enfin de la base de données

Le second objectif du projet concerne le sens même de la révocation. La définition gelée impose, pour tout URI CRL Distribution Point présent, qu’une CRL disponible à cet emplacement contienne le numéro de série. Pour tout URI OCSP dans Authority Information Access, une requête sur ce numéro doit obtenir certStatus = revoked.

L’issue 252 documente depuis 2021 la question que cette rédaction cherche à fermer. Un bit changé dans la base de l’AC suffit-il ? La signature d’un nouvel objet suffit-elle ? Faut-il que l’objet soit publié à l’origine, puis visible derrière le CDN ? Et que faire si CRL et OCSP ne donnent pas encore la même vue ?

Pour le relying party, une décision qui reste dans le système interne ne retire aucune confiance. Même un objet signé mais indisponible ne change pas la réponse obtenue. Le projet place donc l’état terminal au niveau de l’interface de consommation. C’est un progrès de preuve.

Il ne supprime pas la physique de la distribution. Les caches peuvent diverger pendant un temps ; certains répondeurs OCSP produisent une réponse à la demande ; une purge mondiale n’est pas instantanée. Le bon constat est que le point d’arrêt devient testable aux emplacements annoncés, non que chaque client observe exactement la même milliseconde.

Le contraste se dessine alors nettement : l’extérieur peut vérifier la fin, tandis que le début dépend d’un horodatage créé dans l’institution examinée.

Une alerte, puis une population

L’exigence de 120 heures répond à une asymétrie d’information. Le déclarant peut voir un certificat défectueux sans savoir combien d’autres ont suivi le même chemin d’émission. L’AC possède les journaux, les méthodes de validation, l’historique de déploiement et les relations de compte nécessaires pour rechercher les cas frères.

L’incident CNAME de DigiCert fournit une illustration, pas une preuve contrefactuelle. Le rapport indique qu’un tiers avait signalé le problème sans transmettre des numéros de série pourtant connus. Le rapport complet cite ensuite l’insuffisante prise au sérieux des CPR dépourvus de séries parmi les causes profondes et dénombre 83 267 certificats valides émis par la méthode concernée. Le premier indice et la population finale n’étaient pas le même objet.

Le projet évite d’exiger du tiers l’inventaire complet. Un certificat suffit à ouvrir le dossier ; l’AC doit chercher le reste. Cependant, chaque recherche crée ses propres dates. Les 120 heures commencent à la qualification. Pour un certificat supplémentaire, le délai de révocation commence lors de sa première identification.

Il faut donc distinguer l’instant où une requête de population est lancée, celui où le système produit une correspondance et celui où un analyste l’enregistre. Un simple champ « revue terminée » ne permet pas de reconstituer ce trajet. Le reçu devrait conserver périmètre d’ouverture, version de la méthode, début, fin, nombre examiné, nouveaux cas, exceptions et corrections. Les requêtes internes et la liste des clients peuvent rester protégées.

Améliorer la qualité sans effacer le premier signal

Les autres incidents cités par la proposition montrent des frictions différentes. Un déclarant a décrit, dans un ticket SSL.com, une redirection de l’adresse électronique vers un formulaire et une ambiguïté sur le mot « thumbprint » ; le ticket a finalement été classé INVALID. Un ticket GoDaddy a relaté le rejet de pièces jointes contenant des éléments de clés compromises par une adresse publique ; il a été résolu FIXED.

Ces issues ne prescrivent pas un formulaire universel. Une pièce jointe peut être bloquée pour de bonnes raisons. Un formulaire doit contenir le spam et les demandes d’assistance sans rapport. Une clé privée en clair mérite une voie spécialisée. Le projet a raison de ne pas donner à tout message la force d’un ordre de révocation.

Mais la recherche de qualité ne doit pas faire disparaître l’historique. Si un dossier est jugé non exploitable, le texte gelé prévoit en principe une réponse dans les 24 heures suivant cette décision, demandant les éléments manquants lorsque le contact est connu. Si ces éléments arrivent ensuite, leur réception sert de base aux futurs délais.

Le même identifiant de dossier devrait traverser les états : reçu, incomplet, complété, exploitable, examiné. Le délai légal peut partir du complément tout en gardant visible l’existence du premier signal. Sans ce lien, une AC peut respecter localement le nouveau texte tout en présentant le vendredi comme l’origine d’un dossier commencé le lundi.

Un reçu public mince, une preuve protégée plus riche

Le public n’a pas besoin de lire la clé compromise ou l’échange avec l’abonné. Il a besoin de pouvoir joindre les transitions.

Transition Trace minimale
Entrée officielle Canal, version des instructions, heure de réception, identifiant pseudonyme
Qualification Heure, éléments présents ou manquants, code de motif borné
Constat Classe de violation ou de motif, distincte de la recevabilité
Certificats initiaux Nombre protégé et classe de délai de 24 heures ou cinq jours
Recherche de population Périmètre, version de méthode, début, fin, total examiné, nouveaux cas, exceptions
Découvertes supplémentaires Première identification et échéance applicable
Publication URI CRL/OCSP applicables et première observation réussie de l’état révoqué
Reste Désaccords de propagation, coordination, corrections et propriétaire de l’action suivante

Les identifiants peuvent être hachés ou différés. Le contenu du CPR, les clés privées, les comptes, les techniques de détection et les réglages anti-abus doivent rester confidentiels. Un auditeur ou un root program peut contrôler la couche détaillée lorsque la publication créerait un risque.

La distinction de Heng Lu entre couche symbolique et couche de réalité s’applique ici avec prudence. Elle n’est ni une règle Web PKI ni une décision du Forum. Elle rappelle seulement qu’un état ayant une conséquence exécutable doit être relié à son événement réel. Actionable ouvre les délais ; Revoked change la réponse que le relying party peut obtenir. Une étiquette sans trace ne suffit pas.

Le 15 septembre n’est encore qu’une ligne de projet

Au cutoff, la pull request était ouverte et s’appelait toujours SC-XX. Les dernières minutes publiées la classaient parmi les Draft Ballots. La branche gelée porte une date proposée du 15 septembre 2026, mais elle repose encore sur un texte version 2.2.2 alors que main était en 2.2.9.

Il n’est donc pas permis d’annoncer une entrée en vigueur. Il manque dans les sources vérifiées un numéro final, un passage en discussion, des endorseurs formels, un vote, l’examen IPR, une fusion et une politique d’application par les fournisseurs de logiciels. Les Baseline Requirements rappellent eux-mêmes qu’ils ne deviennent obligatoires que lorsqu’ils sont adoptés et appliqués par ces fournisseurs.

Ce statut précoce est précisément le moment où le défaut de preuve coûte le moins cher à corriger. Le projet peut intégrer la branche courante, ajuster ses dates et préciser le reçu avant de figer des obligations dans les outils d’audit.

Relier les deux extrémités

La pull request 622 propose une amélioration réelle : un signalement n’exigerait plus du tiers la connaissance de toute la population, et la révocation se terminerait par une réponse visible plutôt que par une intention interne.

Il reste à donner la même qualité de preuve au départ. Cela ne signifie pas transférer la décision à l’accusateur. L’AC peut rejeter le fond, protéger une enquête et coordonner le remplacement dans le délai applicable. Elle devrait simplement pouvoir montrer quand le dossier officiel est entré, quand il a satisfait le seuil, quand la population a été étendue et quand chaque point de statut a fermé l’intervalle.

Rendre la fin publique sans rendre le début attribuable laisse la moitié du temps hors de la gouvernance. Le reçu proposé referme cette moitié sans exposer ce qui doit rester secret.

Limites de la preuve

Aucune source ne montre qu’une AC a manipulé un horodatage actionable sous cette règle : elle n’est pas en vigueur. Rien ne prouve que le reçu aurait empêché les trois incidents cités. Les tickets ont des faits et des conclusions différentes.

Le texte peut encore évoluer, y compris ses erreurs rédactionnelles, sa date et sa base. Cette analyse porte sur le commit gelé et ne prédit pas le ballot final. Elle ne promet ni synchronisation parfaite des caches, ni publication de toute preuve, ni équivalence entre recevabilité et non-conformité.

Le fait établi est plus étroit : le projet crée des transitions temporelles importantes et rend son état terminal observable. Une preuve minimale peut aussi rendre son point de départ contrôlable.

Sources

  1. Heng Lu, « On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile »
  2. Pull request 622 du dépôt servercert du CA/Browser Forum
  3. Baseline Requirements proposés au commit gelé ef1dda7b…
  4. Baseline Requirements courants au commit main gelé 5c13e270…
  5. Issue 252 : préciser le sens technique de la révocation
  6. Mozilla Bugzilla 1910322 : incident de validation CNAME de DigiCert
  7. Mozilla Bugzilla 1942270 : plainte sur le mécanisme SSL.com
  8. Mozilla Bugzilla 1942241 : plainte sur les pièces jointes GoDaddy
  9. Procès-verbal du SCWG, 13 août 2026
  10. Charte du Server Certificate Working Group
  11. Statuts du CA/Browser Forum