Aller au contenu principal

5. Clients

5. Clients​

Il existe diverses fonctions que les clients des journaux peuvent remplir. Nous décrivons ici quelques clients typiques et comment ils pourraient fonctionner. Toute incohérence peut être utilisée comme preuve qu’un journal ne s’est pas comporté correctement, et les signatures sur les structures de données empêchent le journal de nier ce mauvais comportement.

Tous les clients devraient pratiquer le gossip entre eux, au moins en échangeant des STH ; c’est tout ce qui est requis pour garantir qu’ils ont tous une vue cohérente. Le mécanisme exact de gossip sera décrit dans un document séparé, mais on s’attend à ce qu’il existe une variété de mécanismes.

5.1. Soumetteurs​

Les soumetteurs soumettent des certificats ou des Precertificates au journal comme décrit ci-dessus. Ils peuvent ensuite utiliser le SCT renvoyé pour construire un certificat ou l’utiliser directement dans une poignée de main TLS.

5.2. Client TLS​

Les clients TLS ne sont pas directement clients du journal, mais ils reçoivent des SCT avec ou dans les certificats serveurs. En plus de la validation normale du certificat et de sa chaîne, ils devraient valider le SCT en calculant l’entrée de signature à partir des données du SCT ainsi que du certificat et en vérifiant la signature, en utilisant la clé publique du journal correspondant. Noter que ce document ne décrit pas comment les clients obtiennent les clés publiques des journaux.

Les clients TLS DOIVENT rejeter les SCT dont l’horodatage est dans le futur.

5.3. Moniteur​

Les moniteurs surveillent les journaux et vérifient qu’ils se comportent correctement. Ils surveillent également les certificats d’intérêt.

Un moniteur doit, au minimum, inspecter chaque nouvelle entrée dans chaque journal qu’il surveille. Il peut aussi vouloir conserver des copies complètes des journaux. Pour ce faire, il devrait suivre ces étapes pour chaque journal :

  1. Récupérer la STH courante (section 4.3).

  2. Vérifier la signature de la STH.

  3. Récupérer toutes les entrées dans l’arbre correspondant à la STH (section 4.6).

  4. Confirmer que l’arbre construit à partir des entrées récupérées produit le même hachage que celui de la STH.

  5. Récupérer la STH courante (section 4.3). Répéter jusqu’à ce que la STH change.

  6. Vérifier la signature de la STH.

  7. Récupérer toutes les nouvelles entrées dans l’arbre correspondant à la STH (section 4.6). Si elles restent indisponibles pendant une période prolongée, ceci devrait être considéré comme un mauvais comportement de la part du journal.

  8. Soit :

    1. Vérifier que la liste mise à jour de toutes les entrées génère un arbre avec le même hachage que la nouvelle STH.

    Ou, s’il ne conserve pas toutes les entrées du journal :

    1. Récupérer une preuve de cohérence pour la nouvelle STH avec la STH précédente (section 4.4).

    2. Vérifier la preuve de cohérence.

    3. Vérifier que les nouvelles entrées génèrent les éléments correspondants dans la preuve de cohérence.

  9. Aller à l’étape 5.

5.4. Auditeur​

Les auditeurs prennent des informations partielles sur un journal en entrée et vérifient que ces informations sont cohérentes avec d’autres informations partielles qu’ils possèdent. Un auditeur peut être un composant intégral d’un client TLS ; il peut être un service autonome ; ou il peut être une fonction secondaire d’un moniteur.

Toute paire de STH du même journal peut être vérifiée en demandant une preuve de cohérence (section 4.4).

Un certificat accompagné d’un SCT peut être vérifié contre toute STH datée après l’horodatage du SCT plus le Maximum Merge Delay en demandant une preuve d’audit Merkle (section 4.5).

Les auditeurs peuvent récupérer des STH de temps à autre de leur propre initiative, bien entendu (section 4.3).

Dernière mise à jour le