7. Considérations de sécurité

Avec les CA, les journaux et les serveurs effectuant les actions décrites ici, les clients TLS peuvent utiliser les journaux et les horodatages signés pour réduire la probabilité d’accepter des certificats mal émis. Si un serveur présente un horodatage signé valide pour un certificat, alors le client sait que le certificat a été publié dans un journal. De là, le client sait que le sujet du certificat a eu un certain délai pour remarquer la mauvaise émission et entreprendre une action, comme demander à une CA de révoquer un certificat mal émis. Un horodatage signé n’est pas une garantie que le certificat n’est pas mal émis, puisque le sujet du certificat n’a peut-être pas consulté les journaux ou la CA a peut-être refusé de révoquer le certificat.

En outre, si les clients TLS n’acceptent pas les certificats non journalisés, alors les propriétaires de sites auront une incitation accrue à soumettre des certificats aux journaux, éventuellement avec l’aide de leur CA, augmentant la transparence globale du système.

7.1. Certificats mal émis

Les certificats mal émis qui n’ont pas été publiquement journalisés et n’ont donc pas de SCT valide seront rejetés par les clients TLS. Les certificats mal émis qui ont un SCT provenant d’un journal apparaîtront dans ce journal public dans le délai Maximum Merge Delay, en supposant que le journal fonctionne correctement. Ainsi, la période maximale pendant laquelle un certificat mal émis peut être utilisé sans être disponible pour audit est le MMD.

7.2. Détection d’une mauvaise émission

Les journaux ne détectent pas eux-mêmes les certificats mal émis ; ils s’appuient plutôt sur des parties intéressées, telles que les propriétaires de domaines, pour les surveiller et entreprendre une action corrective lorsqu’une mauvaise émission est détectée.

7.3. Journaux déviant du comportement attendu

Un journal peut mal se comporter de deux façons : (1) en omettant d’incorporer un certificat avec un SCT dans l’arbre de Merkle dans le MMD et (2) en violant sa propriété append-only en présentant deux vues différentes et conflictuelles de l’arbre de Merkle à différents moments et/ou à différentes parties. Les deux formes de violation seront rapidement et publiquement détectables.

La violation du contrat MMD est détectée par les clients du journal demandant une preuve d’audit Merkle pour chaque SCT observé. Ces vérifications peuvent être asynchrones et ne doivent être faites qu’une fois par certificat. Afin de protéger la vie privée des clients, ces vérifications n’ont pas besoin de révéler le certificat exact au journal. Les clients peuvent à la place demander la preuve à un auditeur de confiance (puisque quiconque peut calculer les preuves d’audit à partir du journal) ou demander des preuves Merkle pour un lot de certificats autour de l’horodatage du SCT.

La violation de la propriété append-only est détectée par le gossip à l’échelle du réseau, c’est-à-dire par le fait que tous ceux qui auditent les journaux comparent leurs versions des Signed Tree Heads les plus récentes. Dès que deux Signed Tree Heads conflictuelles pour le même journal sont détectées, ceci constitue une preuve cryptographique de la mauvaise conduite de ce journal.