Perché le CA invece del database globale delle impronte digitali?

In realtà, si tratta di due domande: perché utilizzare le CA anziché un database globale delle impronte digitali e perché utilizzare le CA anziché fare ciò che fa SSH. Non esiste un database di impronte digitali globale per SSH, è infatti l'esatto opposto.

Nel modello SSH, non esiste un modo integrato per ottenere l'impronta digitale di un server se non collegandosi ad esso. Il solito modello di sicurezza è che quando ci si connette a un server per la prima volta da un determinato client, viene richiesto di verificare manualmente l'impronta digitale e, quando ci si connette di nuovo, il client verifica che l'impronta digitale non sia cambiata. Un caso comune in cui questo modello funziona è quando il client si trova su un laptop e si esegue la prima connessione dall'interno della stessa rete attendibile che contiene il server. Oltre a questo, dovresti verificare l'impronta digitale fuori banda, ma la maggior parte degli utenti digita "sì". Questo sistema non scala realmente; è praticabile quando ti connetti solo a una manciata di nuovi host all'anno, ma non per qualcosa come il web dove potresti connetterti a diversi nuovi siti HTTPS ogni giorno.

Se esistesse un database di impronte digitali globale, sarebbe a tutti gli effetti una CA universale. La definizione di CA è che ci si fida di esso quando ti dice che una certa chiave pubblica K appartiene a una certa entità E. Nel protocollo SSL, una CA ti dice questo fornendo un certificato che contiene un'asserzione crittografica che K è il chiave pubblica di E. Un database di impronte digitali, dove si cerca E e si ottiene K o viceversa, si tratta di un'implementazione diversa di una relazione di fiducia. Quindi con un database di impronte digitali globale avremmo un database "troppo grande per fallire" ancora più grande.

Un approccio che evita il problema "too big to fail" è la web of trust utilizzata da PGP. Il principio è che tu sai che K è la chiave di E perché qualcuno che conosci ti dice così. Questo approccio è ragionevolmente adatto per applicazioni come la posta elettronica, perché molte e-mail vengono inviate tra persone che hanno una relazione esistente precedente o che hanno amici in comune. Non è applicabile in un caso come "Voglio collegarmi al sito web di questo commerciante", dove non hai mai sentito parlare di questo commerciante prima di vedere un link ad esso su un sito di comparazione prezzi, ma vuoi sapere che il sito web appartiene a un'entità aziendale che ha lavorato per diversi anni, e non a qualche scammer drive-by che prenderà i tuoi soldi e se ne andrà la prossima settimana.

Avere una singola CA solleva preoccupazioni diverse dal rischio per l'integrità del database delle relazioni di fiducia. Quando un'entità registra una chiave, la CA deve verificare che il dichiarante abbia un credito valido per la sua presunta identità (che l'utente che registra una chiave per "Joe Bloggs" è in realtà chiamato Joe Bloggs, che il dichiarante per "Yoyodine, Inc" . "è in effetti un ufficiale autorizzato di Yoyodine, ...), quindi il dichiarante non può avere privacy rispetto alla CA. Una scelta di CA significa che i dichiaranti possono scegliere a chi inviare la propria identità privata. Una CA gestita dallo stato si troverebbe in un buon posto perché conosce già l'identità del dichiarante, ma quale stato? Le persone potrebbero voler dichiarare identità che non sono note allo stato in cui vivono. Un'altra preoccupazione per una singola CA è che avrebbe il monopolio della registrazione; avere molte CA significa che è improbabile che un'entità sia esclusa dalla partecipazione.

Un modo per ridurre l'impatto di un errore di una CA è quello di avere regolarmente le chiavi certificate da più CA. Questo è qualcosa che le persone spesso fanno in un web di trust in stile PGP: voglio verificare la chiave di Alice, quindi chiedo a Bob, che mi dice che la chiave è corretta. Ma mentre sono sicuro che è Bob a dirmi questo perché ho verificato la sua chiave, non ho completamente fiducia che Bob abbia verificato l'identità di Alice. Quindi chiedo anche a Carol, a Dan e così via. Con molte presunzioni convergenti, ottengo una maggiore certezza che Alice è chi afferma di essere. Allo stesso modo, avere la chiave di un sito Web certificata da più CA e non revocata da nessuno, ridurrebbe i timori che una di queste CA potrebbe essere stata compromessa o potrebbe essere stata negligente nel verificare l'identità del registrante. Tuttavia, ciò richiederebbe aggiornamenti a un sacco di software che verifica i certificati SSL e aumenta il costo della registrazione delle chiavi.

Non riesco a vedere come questo sarebbe un vantaggio. Attualmente disponiamo di molti CA, il che significa che se uno è interrotto per qualche motivo (ad esempio Diginotar) possiamo semplicemente (beh, relativamente semplicemente) revocare i certificati per quella CA.

Se hai appena avuto un grande dB, cosa succede quando viene rotto, deliberatamente o accidentalmente? Non hai opzioni di fallback utili o rapide.