1. Informal Introduction (Introduzione informale)

Certificate Transparency (CT) (trasparenza dei certificati) mira a mitigare il problema dei certificati emessi erroneamente fornendo log pubblicamente verificabili, solo-append e non fidati di tutti i certificati emessi. I log sono pubblicamente verificabili affinché sia possibile per chiunque controllare la correttezza di ciascun log e monitorare quando nuovi certificati vi vengono aggiunti. I log non impediscono di per sé l'emissione errata, ma assicurano che le parti interessate (in particolare quelle nominate nei certificati) possano rilevare tale emissione errata. Si noti che si tratta di un meccanismo generale, ma in questo documento ne descriviamo solo l'uso per i certificati di server TLS pubblici emessi da public certificate authorities (CA) (autorità di certificazione pubbliche).

Ogni log consiste in catene di certificati, che possono essere inviate da chiunque. Ci si attende che le CA pubbliche contribuiscano con tutti i certificati di nuova emissione a uno o più log; ci si attende anche che i titolari di certificati contribuiscano con le proprie catene. Per evitare che i log vengano sommersi da spam fino a renderli inutili, è richiesto che ogni catena sia radicata in un certificato CA noto. Quando una catena viene inviata a un log, viene restituito un signed timestamp (timestamp firmato), che in seguito può essere usato per fornire ai client la prova che la catena è stata inviata. I client TLS possono quindi richiedere che tutti i certificati che vedono siano stati registrati.

Coloro che sono preoccupati per l'emissione errata possono monitorare i log, richiedendo loro periodicamente tutte le nuove voci, e possono così verificare se per i domini di cui sono responsabili sono stati emessi certificati che non si aspettavano. Cosa facciano con queste informazioni, in particolare quando scoprono che è avvenuta un'emissione errata, è al di fuori dell'ambito di questo documento, ma in generale possono invocare i meccanismi aziendali esistenti per gestire certificati emessi erroneamente. Naturalmente, chiunque lo desideri può monitorare i log e, se ritiene che un certificato sia stato emesso in modo scorretto, può intraprendere azioni come ritiene opportuno.

Allo stesso modo, coloro che hanno visto signed timestamps da un particolare log possono in seguito richiedere una proof of inclusion (prova di inclusione) da quel log. Se il log non è in grado di fornirla (o, anzi, se il certificato corrispondente è assente dalle copie del log in possesso dei monitor), ciò costituisce evidenza di funzionamento scorretto del log. L'operazione di verifica è asincrona per consentire alle connessioni TLS di procedere senza ritardi, nonostante problemi di connettività di rete e le imprevedibilità dei firewall.

La proprietà append-only (solo-append) di ciascun log è ottenuta tecnicamente mediante Merkle Trees (alberi di Merkle), che possono essere usati per mostrare che qualsiasi particolare versione del log è un sovrainsieme di qualsiasi particolare versione precedente. Allo stesso modo, gli alberi di Merkle evitano la necessità di fidarsi ciecamente dei log: se un log tenta di mostrare cose diverse a persone diverse, ciò può essere rilevato efficientemente confrontando le radici dell'albero e le consistency proofs (prove di coerenza). Allo stesso modo, altri comportamenti scorretti di qualsiasi log (ad esempio, l'emissione di signed timestamps per certificati che poi non registrano) possono essere rilevati ed efficacemente provati al mondo intero.

1.1 Requirements Language (Linguaggio dei requisiti)

Le parole chiave "DEVE", "NON DEVE", "RICHIESTO", "DEVE", "NON DEVE", "DOVREBBE", "NON DOVREBBE", "RACCOMANDATO", "PUÒ" e "OPZIONALE" in questo documento DEVONO essere interpretate come descritto in RFC 2119 [RFC2119].

1.2 Data Structures (Strutture dati)

Le strutture dati sono definite secondo le convenzioni esposte nella Sezione 4 di [RFC5246].