1. Introduction informelle

La transparence des certificats (Certificate Transparency) vise à atténuer le problème des certificats mal émis en fournissant des journaux publics, vérifiables, uniquement append-only et non dignes de confiance a priori, de tous les certificats émis. Les journaux sont publiquement vérifiables afin qu’il soit possible pour quiconque de vérifier l’exactitude de chaque journal et de surveiller l’ajout de nouveaux certificats. Les journaux n’empêchent pas eux-mêmes une mauvaise émission, mais ils garantissent que les parties intéressées (notamment celles nommées dans les certificats) peuvent détecter une telle émission incorrecte. Il s’agit d’un mécanisme général, mais dans ce document, nous ne décrivons que son usage pour les certificats serveur TLS publics émis par des autorités de certification (CA) publiques.

Chaque journal est constitué de chaînes de certificats, que quiconque peut soumettre. On s’attend à ce que les CA publiques contribuent tous leurs certificats nouvellement émis à un ou plusieurs journaux ; on s’attend également à ce que les détenteurs de certificats contribuent leurs propres chaînes. Afin d’éviter que les journaux ne soient spammés jusqu’à l’inutilité, il est requis que chaque chaîne soit ancrée dans un certificat de CA connu. Lorsqu’une chaîne est soumise à un journal, un horodatage signé est renvoyé, qui peut ensuite servir de preuve auprès des clients que la chaîne a été soumise. Les clients TLS peuvent ainsi exiger que tous les certificats qu’ils voient aient été journalisés.

Ceux qui se préoccupent d’une mauvaise émission peuvent surveiller les journaux en leur demandant régulièrement toutes les nouvelles entrées, et peuvent ainsi vérifier si des certificats ont été émis pour des domaines dont ils sont responsables alors qu’ils ne s’y attendaient pas. Ce qu’ils font de cette information, en particulier lorsqu’ils constatent qu’une mauvaise émission s’est produite, dépasse le cadre de ce document ; en général, ils peuvent invoquer les mécanismes commerciaux existants pour traiter les certificats mal émis. Bien entendu, quiconque le souhaite peut surveiller les journaux et, s’il estime qu’un certificat est incorrectement émis, entreprendre l’action qui lui semble appropriée.

De même, ceux qui ont vu des horodatages signés provenant d’un journal particulier peuvent ensuite exiger une preuve d’inclusion auprès de ce journal. Si le journal est incapable de la fournir (ou, en effet, si le certificat correspondant est absent des copies du journal détenues par les moniteurs), cela constitue une preuve de fonctionnement incorrect du journal. La vérification est asynchrone afin de permettre aux connexions TLS de se poursuivre sans délai, malgré les problèmes de connectivité réseau et les aléas des pare-feu.

La propriété append-only de chaque journal est techniquement obtenue au moyen d’arbres de Merkle (Merkle Trees), qui permettent de montrer qu’une version donnée du journal est un sur-ensemble d’une version antérieure donnée. De même, les arbres de Merkle évitent d’avoir à faire aveuglément confiance aux journaux : si un journal tente de montrer des choses différentes à différentes personnes, cela peut être détecté efficacement en comparant les racines d’arbre et les preuves de cohérence. De même, d’autres comportements incorrects d’un journal (par exemple, émettre des horodatages signés pour des certificats qu’il ne journalise ensuite pas) peuvent être détectés et prouvés efficacement au monde entier.

1.1. Langage des exigences

Les mots-clés « MUST » (DOIT), « MUST NOT » (NE DOIT PAS), « REQUIRED » (REQUIS), « SHALL » (DOIT), « SHALL NOT » (NE DOIT PAS), « SHOULD » (DEVRAIT), « SHOULD NOT » (NE DEVRAIT PAS), « RECOMMENDED » (RECOMMANDÉ), « MAY » (PEUT) et « OPTIONAL » (FACULTATIF) dans ce document doivent être interprétés comme décrit dans le RFC 2119 [RFC2119].

1.2. Structures de données

Les structures de données sont définies selon les conventions exposées à la section 4 de [RFC5246].