Perché i keyserver PGP non applicano il double-opt-in?

I server chiave non possono mai essere intesi come fonte di fiducia e chiavi valide. Il loro unico compito è scambiare le chiavi, quindi gli utenti di OpenPGP possono utilizzare la rete di fiducia costituita dalle certificazioni tra le chiavi per convalidare quelle di fiducia.

L'accesso a un indirizzo di posta elettronica non implica la rappresentazione

Affidarsi a una chiave è (per la maggior parte delle persone) qualcosa di più della semplice verifica di un indirizzo di posta elettronica una volta. Gli indirizzi di posta tendono a cambiare, a invalidare, persino a essere nuovamente assegnati in seguito.

Convalidare un indirizzo email basato sulla fiducia richiederebbe una qualche forma di invalidazione, es. rimozione. Ma come dovrebbe essere distribuita, ad esempio, una revoca o altre modifiche?

Alcuni server chiave!

Ma ci sono server chiave che lo fanno, e quindi assumono il ruolo di un'autorità di certificazione. Vi siete mai chiesti delle certificazioni rilasciate dalla chiave di verifica della directory globale di PGP? Questi sono emessi dal servizio di directory globale PGP dopo aver convalidato l'indirizzo di posta contenuto in un UID, invalideranno dopo un dato tempo senza ri-approvazione (sei mesi, se ricordo male) e la tua chiave verrà rimossa dal server se la certificazione è scaduta.

Ma ricorda: questo server chiave è diverso dagli altri, in quanto offre un'autenticazione molto semplice della proprietà delle chiavi, ma non supporta il "modo" di OpenPGP per convalidare le chiavi utilizzando la rete di fiducia.

Come definire le chiavi valide?

Poiché non esiste un "istituto di fiducia" centrale, nessuna autorità di certificazione (o anche non diverse centinaia di loro, come in X.509); chi dovrebbe definire a chi fidarsi? L'operatore del server chiave? Questo al meglio può ridurre il numero di chiavi disponibili per ordine di grandezza, in realtà forse a poche decine o centinaia di chiavi fidate dell'operatore, rispetto a milioni di chiavi per lo più non ancora collegate al web di OpenPGP di fiducia.

Inoltre, ogni utente di OpenPGP ha potenzialmente il suo proprie regole per decidere come convalidare le chiavi , anche se queste potrebbero essere piuttosto simili la maggior parte del tempo.

I server chiave costituiscono semplicemente un metodo per lo scambio di dati tra i client OpenPGP. e di solito non assumono il ruolo di un'autorità di certificazione.

Server delle chiavi sincronizzati

La maggior parte dei server delle chiavi si sincronizzano tra loro . Già quelli elencati nel pool di server delle chiavi SKS ne elencano circa duecento, la maggior parte gestiti da persone che persino non lo fanno Ci conosciamo.

Avere un'infrastruttura di server chiavi decentralizzata è cruciale contro diversi attacchi (denial of service, cancellazione delle chiavi , con un registro centrale di ciò che viene richiesto), specialmente da quelli che hanno accesso a grandi porzioni di una rete (ISP, governi).

Ma come dovrebbe essere raggiunta la verifica dell'indirizzo email in una rete distribuita di server non collegati che non si fidano l'uno dell'altro? L'unica possibilità (almeno, nessun altro è stato proposto finora) è di replicare tutto, e ogni server chiave dovrebbe decidere sulla validità.

Vorresti approvare ciascuno dei tuoi indirizzi mail su oltre 200 server delle chiavi in intervalli di tempo specifici (e molto probabilmente diversi e piuttosto brevi)?

È molto importante capire che i server di chiavi OpenPGP sono autorità di certificazione non . Non sono responsabili per la verifica delle chiavi. OpenPGP utilizza un modello di trust decentralizzato, quindi è compito dell'utente verificare una chiave controllando direttamente l'impronta digitale o utilizzando la rete di fiducia (come già detto).

Quando le persone usano i server delle chiavi per scaricare una chiave per un dato indirizzo e-mail senza alcuna ulteriore convalida, fondamentalmente fraintendono il modello di fiducia di OpenPGP. Non è colpa del keyserver.

Ovviamente i keyserver potrebbero introdurre una verifica di base per ridurre la quantità di chiavi della spazzatura. Tuttavia, ciò renderebbe più sfocata la linea tra keyserver e CA e potrebbe creare un falso senso di sicurezza. Il fatto che qualcuno sia stato in grado di leggere un link all'interno di una e-mail di conferma non crittografata non prova nulla, perché l'e-mail potrebbe essere stata catturata molto bene durante il transito. Quindi un server di chiavi che offre "chiavi verificate" basate su questo metodo starebbe camminando su ghiaccio sottile.

Lo scopo delle parti che firmano le chiavi non è controllare gli indirizzi e-mail. Come già suggerisce il nome, riguardano i tasti . Per essere precisi: in genere, un partecipante A controlla l'identità di un altro partecipante B, chiede l'impronta digitale di B e quindi firma il tasto corrispondente. Quindi, se voglio comunicare con B e già ho fiducia in A, posso usare quella chiave firmata. Ovviamente B potrebbe mentire e fornire un falso indirizzo e-mail, ma questo è un problema sociale, non tecnico. Se una persona si rifiuta semplicemente di avere una conversazione privata via e-mail, nessun protocollo lo risolverà.

Per quanto riguarda il doppio opt-in, si desidera eseguire il controllo una sola volta anziché una volta per ciascun server nella rete. Ciò significa che i controlli non sono una prova nemmeno contro un singolo server di chiavi che accetta chiavi senza controllo e non esiste un modo semplice per verificare quale server ha accettato una chiave. Si poteva progettare un protocollo diverso che includeva la verifica di quale server accettasse una chiave, ma la transizione sarebbe stata dura.

Il modo normale per verificare l'indirizzo e-mail di una chiave PGP dopo la firma di una chiave è di inviare la chiave firmata, crittografata alla chiave per quell'indirizzo e lasciare decrittografare il proprietario e caricarlo sui keyserver stessi. Non lo si incorpora nel normale key ring pubblico fino a quando non lo si scarica dal server delle chiavi o si ottiene una copia firmata dal proprietario della chiave. Si potrebbe vedere questo come una forma di sicurezza TOFU (fiducia al primo utilizzo) simile al modo in cui le chiavi SSH sono spesso gestite. Ci sono strumenti per facilitare questo modello come Pius e