No. Il modello di federazione del pool SKS ha diversi problemi in termini di affidabilità, resistenza all'abuso, privacy, ed usabilità. Potremmmo fare qualcosa di simile, ma keys.openpgp.org non sarà mai parte del pool SKS.
Per il momento, no. Vogliamo decentralizzare keys.openpgp.org prima o poi. Con più server gestiti da più agenti indipendenti, possiamo auspicabilmente migliorare ulteriormente l'affidabilità di questo servizio.
Diverse persone si sono offerte di aiutare "facendo girare un'istanza del server Hagrid". Appreziamo molto l'offerta, ma probabilmente non avremo mai un modello di federazione "aperta" come SKS, dove chiunque può gestire un'istanza e divenire parte del "pool". Questo per due ragioni:
Richiediamo il consenso esplicito per distribuire le informazioni identificative. Le identità che non sono indirizzi email, come immagini o URL di siti web, non offrono alcun modo pratico per chiedere questo consenso.
Nota: Alcuni software OpenPGP creano chiavi con email formattati incorrettamente. Questi indirizzi potrebbero non essere riconosciuti correttamente su keys.openpgp.org.
Un indirizzo email può essere associato solo con una singola chiave. Quando un indirizzo è verificato per una nuova chiave, non appare più in nessuna chiave per cui era stato precedentemente verificato. Leinformazioni non identificative vengono comunque distribuite per tutte le chiavi.
Questo significa che una ricerca per indirizzo email restituirà una sola chiave, non diversi candidati. Questo elimina una scelta impossibile per l'utente ("Quale chiave è quella giusta?"), e rende la ricerca delle chiavi per email molto più semplice.
Usiamo uno standard moderno chiamato MTA-STS, oltre a STARTTLS Everywhere della EFF, per essere sicuri che le mail di verifica siano inviate in maniera sicura. Questo protegge dalle intercettazioni durante la consegna.
Il meccanismo MTA-STS dipende dalla corretta configurazione dei server email. Puoi eseguire questo test per vedere se il tuo provider email lo supporta. Se la voce "MTA-STS" sulla sinistra non è una spunta verde, chiedi al tuo provider di aggiornare la sua configurazione.
In sintesi: No.
Una "firma di terza parte" è una firma su una chiave che è stata fatta con una qualche altra chiave. Più comunemente, queste sono firme prodotte quando si "firma la chiave di qualcuno", che è la base per la "Rete della Fiducia". Per svariate ragioni, queste firme non vengono attualmente distribuite da keys.openpgp.org.
La ragione principale è lo spam. Le firme di terze parti consentono di allegare dati a piacere alla chiave di chiunque, e niente impedisce a un utente malintenzionato di allegare così tanti megabyte di ciarpame a una chiave da renderla praticamente inutilizzabile. Anche peggio, potrebbero allegare contenuto offensivo o illegale.
Ci sono delle idee per risolvere questo problema. Per esempio, le firme potrebbero essere distribuite con la chiave del firmatario, invece che del firmato. In alternativa, potremmo richiedere una firma incrociata dal firmatario prima della distribuzione per supportare un flusso a-la-caff. Se c'è abbastanza interesse, siamo aperti a lavorare con gli altri progetti OpenPGP ad una soluzione.
Il servizio keys.openpgp.orgè mirato a distribuire e far reperire le chiavi, non ad essere una Certification Authority de facto. Le implementazioni dei client che vogliono offrire una comunicazione verificata dovrebbero fare affidamento sul loro modello di fiducia.
Quando una chiave OpenPGP segnala una delle sue identità come revocata, questa identità non dovrebbe essere più ritenuta valida per la chiave, e questa informazione dovrebbe essere idealmente distribuita a tutti i client OpenPGP che conoscono già l'identità appena revocata.
Sfortunatamente, attualmente non c'è un buon modo di distribuire le revoche che non riveli anche l'identità revocata stessa. Non vogliamo distribuire le identità revocate, quindi non possiamo distribuire l'identità affatto.
Ci sono delle soluzioni proposte per questo problema, che consentono la distribuzione delle revoche senza rivelare anche l'identità stessa. Ma finora non c'è stata nessuna specifica finale, o supporto in alcun software OpenPGP. Speriamo che una soluzione sia individuata nell'immediato futuro, e aggiungeremo il supporto su keys.openpgp.org appena possibile.
Alcuni keyserver supportano la ricerca di chiavi per parte di indirizzo email. Questo consente di reperire non solo le chiavi, ma anche gli indirizzi, con una query del tipo "chiavi per indirizzi chiocciola gmail punto com". Questo pone a tutti gli effetti gl iindirizzi di tutte le chiavi su quei keyserver in una lista pubblica.
Una ricerca per indirizzo email su keys.openpgp.org restituisce una chiave solo se corrisponde esattamente all'indirizzo inserito. In questo modo, un utente normale può reperire le chiavi associate con qualsiasi indirizzo conoscano già, ma non possono scoprire alcun nuovo indirizzo email. Questo previene agli utenti malintenzionati o agli spammer di ottenere facilmente una lista di tutti gli indirizzi email presenti nel server.
Abbiamo resto questa restrizione parte della nostra privacy policy, il che vuol dire che non la cambieremo senza chiedere esplicito consenso agli utenti.
Certo!
Se hai Tor installato,
puoi raggiungere keys.openpgp.org anonimamente come un servizio onion:
zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion
È un problema con le attuali versioni di GnuPG. Se provi a aggiornare una chiave da keys.openpgp.org che non contiene informazioni identificative, GnupG si rifiuterà di gestire la chiave:
$ gpg --receive-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E
gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E: no user ID
Stiamo lavorando con il team GnuPG per risolvere questo problema.