Autorità di certificazione
The email client would automatically look up the PGP key of all receivers in key stores (first local, then public keyservers, ideally provided by the receiving email provider) and encrypt the mail with these keys. Ideally, we would use trusted keys by regular PGP standards. However, we would fall back to any suitable key with less trust, down to a complete unknown key if required.
Questa è una pessima idea. Tutti possono generare chiavi per ogni indirizzo di posta. Senza alcun percorso di fiducia, non hai la possibilità di decidere qual è la chiave giusta. Invece di ulteriori argomentazioni, dai un'occhiata ai risultati dei server chiave per [email protected] . Non aspettarti che qualsiasi di loro appartenga a chi dichiara di essere.
On the sending side, any email client would automatically create a PGP key locally and publish the public key part on the email provider's keyserver.
Ora stiamo seguendo un percorso più ragionevole. Ma: questo in qualche modo contraffa l'idea dietro OpenPGP. La fiducia non è definita da quale server delle chiavi è memorizzato, ma quali chiavi sono attendibili. Stai cercando un'autorità di certificazione (sì, alla fine praticamente la stessa cosa che usa X.509). Ce ne sono già alcuni nel mondo OpenPGP, dai un'occhiata a CAcert .
Il tuo provider potrebbe anche essere un'autorità di certificazione (in una certa misura, ti stai già fidando di lui). Per fare ciò, firmeresti e (pienamente) ti fidi della sua chiave di autorità di certificazione, in cambio firmi tutte le chiavi generate per i suoi stessi utenti. OpenPGP può fare tutto questo fuori dalla scatola; non c'è bisogno di cambiarlo. Devi solo far capire e implementare le persone.
Un Web Web of Trust
The only "new" idea here would be to automatically manage trust by exploiting social assumptions. The main assumption would be that two parties continuously exchanging emails somehow know each other and can identify each other by the contents of the mails exchanged. With each email exchange, the email clients of both parties would increase their internal trust score for the other party's key. This internal trust score would be applied like traditional Web-of-Trust confidence levels to build up an automated Web-of-Trust.
Ora stiamo arrivando a un concetto completamente diverso, che è già noto come pinning del certificato (ma non ho sentito di essere implementato per OpenPGP).
Sì, questo potrebbe essere ragionevole per le persone con cui hai già avuto contatti. Ma rende le cose molto più complicate, specialmente per quanto riguarda il calcolo della fiducia. Ciò richiederebbe un calcolo della fiducia probabilistico per poter gestire il gran numero di fiducia piuttosto bassa emessa da tale sistema, come proposto da Maurer et al. nel 1996: Modellazione di un'infrastruttura a chiave pubblica ; forse insieme all'emissione automatizzata di fiducia.
Conclusione
La tua prima proposta, i fornitori che agiscono come autorità di certificazione ha in effetti un certo fascino, è compatibile con OpenPGP e piuttosto facile da implementare. Non sono sicuro che Google abbia piani simili per il suo Fine per terminare il progetto .
For me, this seems like a suitable approach for the public part of the key management issue. It does not solve the private part (e. g. getting the private key to all mobile devices). We also inherit all known issues of PGP.
I modelli probabilistici sono già stati proposti quasi vent'anni fa, non c'era nessuno che li raccogliesse. Se fai scorrere le citazioni per la carta collegata sopra , sembra anche che un bel po 'di pubblicazioni sostengano di avere soluzioni per la tua proposta. Un grosso problema è che non sarebbe più compatibile con OpenPGP (come definito da RFC 4880) e l'introduzione di nuovi sistemi nel modo in cui ottengono l'accettazione non è molto semplice. Inoltre, è ancora più difficile capire cosa sta succedendo nei modelli probabilistici.
Un'altra cosa è che devi ancora insegnare alle persone come usare OpenPGP e capire il concetto di Web of Trust. Questo non è un problema tecnico (anche se potrebbe essere più complicato del necessario); non esiste una soluzione tecnica semplice per la sicurezza. Non basta far credere alle persone che la loro comunicazione sia sicura quando non sono in grado di capire cosa sta succedendo, le cose brutte accadono se qualcuno lo fa , o un orribile mazzo di chiavi non revocate e licenziate sui server delle chiavi.
Ulteriori note
- The internal trust score needs to be very fine-grained in order to allow automated increments and calculation (e. g. 0..1 range with IEEE-754 double precision).
Off topic su ciò che è realmente discusso in questo Q & A, ma comunque: questo non è un caso d'uso ragionevole per i valori a virgola mobile. I numeri in virgola mobile hanno un'alta risoluzione intorno a 0, ma questo si degrada rapidamente quando si va verso valori più grandi (mi è stato detto che puoi osservarlo in Minecraft, dove si verificano alcuni salti divertenti quando ti avvicini ai confini del mondo). Perché non basta mapparlo all'intero intero a 64 bit (probabilmente anche a 32 bit sarebbe più che bello) che occupa lo stesso spazio, ma con una risoluzione costante di tutti i valori. Usando variabili a virgola mobile dovresti limitarti a un intervallo di valori molto piccolo (0..1 probabilmente andrebbe bene, ma comunque devi tratta con effetti divertenti non troppo importanti per il calcolo probabilistico e spreca un po 'di memoria e potenza di calcolo.