5. Clients (Client)

5. Clients (Client)

Vi sono varie funzioni diverse che i client dei log possono svolgere. Qui descriviamo alcuni client tipici e come potrebbero funzionare. Qualsiasi inconsistenza può essere usata come prova che un log non si è comportato correttamente, e le firme sulle strutture dati impediscono al log di negare tale comportamento scorretto.

Tutti i client dovrebbero fare gossip tra loro, scambiando almeno le STH; ciò è tutto ciò che è richiesto per assicurare che abbiano tutti una vista coerente. Il meccanismo esatto per il gossip sarà descritto in un documento separato, ma ci si attende che vi sarà una varietà.

5.1 Submitters (Invianti)

Gli invianti inviano certificati o Precertificate al log come descritto sopra. Possono poi usare l'SCT restituito per costruire un certificato o usarlo direttamente in un handshake TLS.

5.2 TLS Client (Client TLS)

I client TLS non sono direttamente client del log, ma ricevono SCT insieme o nei certificati del server. Oltre alla validazione normale del certificato e della sua catena, dovrebbero validare l'SCT calcolando l'input della firma dai dati SCT nonché dal certificato e verificando la firma, usando la chiave pubblica del log corrispondente. Si noti che questo documento non descrive come i client ottengono le chiavi pubbliche dei log.

I client TLS DEVONO rifiutare SCT il cui timestamp è nel futuro.

5.3 Monitor (Monitor)

I monitor osservano i log e verificano che si comportino correttamente. Osservano anche i certificati di interesse.

Un monitor deve, almeno, ispezionare ogni nuova voce in ciascun log che osserva. Può anche voler mantenere copie intere dei log. Per farlo, dovrebbe seguire questi passi per ciascun log:

1. Recuperare la STH corrente (Sezione 4.3).

2. Verificare la firma della STH.

3. Recuperare tutte le voci nell'albero corrispondente alla STH (Sezione 4.6).

4. Confermare che l'albero costruito dalle voci recuperate produce lo stesso hash di quello nella STH.

5. Recuperare la STH corrente (Sezione 4.3). Ripetere finché la STH non cambia.

6. Verificare la firma della STH.

7. Recuperare tutte le nuove voci nell'albero corrispondente alla STH (Sezione 4.6). Se restano indisponibili per un periodo prolungato, ciò dovrebbe essere considerato comportamento scorretto da parte del log.

8. In alternativa:

   1. Verificare che l'elenco aggiornato di tutte le voci generi un albero con lo stesso hash della nuova STH.

   Oppure, se non mantiene tutte le voci del log:

   2. Recuperare una consistency proof per la nuova STH rispetto alla STH precedente (Sezione 4.4).

   3. Verificare la consistency proof.

   4. Verificare che le nuove voci generino gli elementi corrispondenti nella consistency proof.

9. Tornare al passo 5.

5.4 Auditor (Verificatore)

I verificatori prendono come input informazioni parziali su un log e verificano che tali informazioni siano coerenti con altre informazioni parziali in loro possesso. Un verificatore può essere un componente integrale di un client TLS; può essere un servizio autonomo; oppure può essere una funzione secondaria di un monitor.

Qualsiasi coppia di STH dallo stesso log può essere verificata richiedendo una consistency proof (Sezione 4.4).

Un certificato accompagnato da un SCT può essere verificato rispetto a qualsiasi STH datata dopo il timestamp SCT + il Maximum Merge Delay richiedendo un Merkle audit proof (Sezione 4.5).

I verificatori possono recuperare STH di tanto in tanto per propria iniziativa, naturalmente (Sezione 4.3).