7. Security Considerations (Considerazioni sulla sicurezza)

Con CA, log e server che eseguono le azioni descritte qui, i client TLS possono usare i log e i timestamp firmati per ridurre la probabilità di accettare certificati emessi erroneamente. Se un server presenta un timestamp firmato valido per un certificato, allora il client sa che il certificato è stato pubblicato in un log. Da ciò, il client sa che il soggetto del certificato ha avuto del tempo per notare l'emissione errata e intraprendere qualche azione, come chiedere a una CA di revocare un certificato emesso erroneamente. Un timestamp firmato non è garanzia che il certificato non sia stato emesso erroneamente, poiché il soggetto del certificato potrebbe non aver controllato i log o la CA potrebbe aver rifiutato di revocare il certificato.

Inoltre, se i client TLS non accetteranno certificati non registrati, i titolari di siti avranno maggiore incentivo a inviare certificati ai log, possibilmente con l'assistenza della loro CA, aumentando la trasparenza complessiva del sistema.

7.1 Misissued Certificates (Certificati emessi erroneamente)

I certificati emessi erroneamente che non sono stati pubblicamente registrati, e quindi non hanno un SCT valido, saranno rifiutati dai client TLS. I certificati emessi erroneamente che hanno un SCT da un log compariranno in quel log pubblico entro il Maximum Merge Delay, assumendo che il log operi correttamente. Pertanto, il periodo massimo durante il quale un certificato emesso erroneamente può essere usato senza essere disponibile per la verifica è l'MMD.

7.2 Detection of Misissue (Rilevazione di emissione errata)

I log non rilevano di per sé certificati emessi erroneamente; si affidano invece a parti interessate, come i titolari di domini, per monitorarli e intraprendere azioni correttive quando viene rilevata un'emissione errata.

7.3 Misbehaving Logs (Log che non si comportano correttamente)

Un log può comportarsi scorrettamente in due modi: (1) non incorporando un certificato con un SCT nel Merkle Tree entro l'MMD e (2) violando la sua proprietà append-only presentando due viste diverse e conflittuali del Merkle Tree in momenti diversi e/o a parti diverse. Entrambe le forme di violazione saranno prontamente e pubblicamente rilevabili.

La violazione del contratto MMD è rilevata dai log client che richiedono un Merkle audit proof per ciascun SCT osservato. Questi controlli possono essere asincroni ed è sufficiente eseguirli una volta per certificato. Per proteggere la privacy dei client, questi controlli non hanno l'obbligo di rivelare il certificato esatto al log. I client possono invece richiedere la prova da un verificatore fidato (poiché chiunque può calcolare le audit proof dal log) o richiedere prove Merkle per un lotto di certificati intorno al timestamp SCT.

La violazione della proprietà append-only è rilevata da gossip globale, cioè tutti coloro che verificano i log confrontando le loro versioni delle ultime Signed Tree Heads. Non appena vengono rilevate due Signed Tree Heads conflittuali per lo stesso log, ciò è prova crittografica del comportamento scorretto di quel log.