Summary

  • Le projet STI Certificate Transparency, version 05 est encore un Internet-Draft du groupe STIR, en dernière consultation IETF jusqu'au 5 novembre 2026. Il propose d'inscrire les certificats d'identité téléphonique dans des journaux vérifiables.
  • L'autorité de certification soumet un précertificat; le journal remet un SCT, promesse signée de l'intégrer avant la fin du délai maximal de fusion. Le certificat définitif porte ce reçu. Le service qui vérifie l'appel contrôle le certificat et le SCT sans consulter le journal pendant l'appel.
  • Un contrôleur séparé relève les nouvelles inscriptions et compare TNAuthList ainsi que le nom de l'entité à son inventaire de numéros ou de codes de fournisseur. Sa découverte et la décision de révoquer suivent un autre calendrier.

Supposons deux certificats, chacun muni d'un reçu de journal, qui attribuent le même numéro à deux organismes différents. Un appel signé avec le second arrive avant que le contrôleur du numéro ait lu cette nouvelle entrée. Le service de vérification dispose des signatures nécessaires pour examiner le certificat; il ne dispose pas encore du jugement de l'ayant droit sur cette revendication. Cette scène éprouve la logique du projet; elle ne décrit aucune fraude établie.

Le projet adapte la mécanique de RFC 6962 aux certificats STI. RFC 8226 fixe l'extension TNAuthList qui associe certificats, numéros et codes de fournisseur; RFC 9060 traite la délégation de numéros. Une autorité STI envoie son précertificat et les certificats intermédiaires. Le journal vérifie que la chaîne rejoint une racine qu'il accepte et dont il publie la liste. Il renvoie alors un SCT destiné au certificat final.

Le reçu est une promesse assortie d'une échéance

Le SCT engage le journal à inscrire le précertificat dans son arbre de Merkle avant la fin du délai maximal de fusion. Ce reçu naît avant le travail du contrôleur. Une tête d'arbre signée, une preuve d'inclusion et une preuve de cohérence entre deux états permettent ensuite à l'auditeur de vérifier l'inscription et la continuité de l'historique. Le reçu, l'inscription et l'audit sont trois actes. Les fondre dans une seule pastille « vérifié » fait disparaître le temps.

La séparation protège la voie rapide. La section 7.2 demande que les certificats utilisés pour signer les appels embarquent leurs SCT. Le service d'authentification peut vérifier et mémoriser le résultat lors de l'activation du certificat. Le service de vérification contrôle la signature PASSporT, la chaîne vers une racine STI acceptée et la signature du SCT avec la clé d'un journal reconnu. Le texte écarte toute requête synchrone au journal pendant l'appel. Celui-ci n'attend ni la réponse du journal public ni la fin de la tournée du contrôleur.

Ce gain de temps crée une obligation ailleurs. Le journal reconnaît une chaîne de certificats, puis promet une inscription publique. Il ne tient pas l'inventaire commercial ou réglementaire de chaque numéro. Le contrôleur doit connaître les numéros ou codes qu'il défend, récupérer les nouvelles entrées depuis sa dernière tête d'arbre, décoder TNAuthList et comparer le nom du titulaire annoncé. Si un second organisme apparaît, il déclenche une alerte. Un contrôleur configuré sur le mauvais périmètre peut lire parfaitement le journal et manquer l'usurpation qu'il cherchait.

Qui reçoit l'alarme, qui peut couper le certificat ?

Après une alerte, le projet renvoie la réponse aux institutions du système STI. Il évoque la révocation du certificat par l'autorité émettrice ou le retrait d'une autorité de la liste des racines acceptées. La seconde mesure touche un ensemble plus large de certificats. Le contrôleur produit un signal; l'autorité de correction appartient à un autre acteur. Sans responsable nommé pour cette décision, la belle preuve cryptographique s'arrête à une boîte de réception.

Le détail des interfaces renforce ce constat. Le projet reprend les opérations /ct/v1/ de RFC 6962 et recommande un chemin /stict/v1/ plus clair pour l'exploitation. Changer le préfixe de l'URL ne règle ni la surveillance de tous les journaux pertinents ni la mise à jour de la liste des numéros. Ces tâches demandent des responsables et des délais mesurés.

La pièce manquante pour juger un déploiement est une chronologie réelle entre émission, inclusion, détection d'un conflit et décision finale. Le projet ne chiffre ni ce délai ni une fréquence de fraude. Pour un opérateur, l'enjeu est de financer l'œil qui lit le registre aussi sûrement que la machine qui vérifie l'appel. La vitesse de la seconde ne dispense pas du premier.

Projet STI CT · RFC 6962 · RFC 8226 · RFC 9060 · RFC 8224