On 25/10/11 21:11, Mark H. Wood wrote: > So, to summarize what I think I've been hearing: the problem which > remains to be solved (if it is a problem) is a nontechnical one, and > no amount of technical wizardry will solve it. The most that can be > done now is to be ready to help someone who fears for his privacy and > asks, "what can I do?" > > Maybe someday there will be a panic and everybody will be asking. > It's good to have an answer.
I think there are two major technical problems which would make things a lot easier if they were solved. 1.) A system of mapping email addresses to public keys 2.) A system of distributing private keys between all of a users email clients automatically. These can be tackled independently. For #2 I'd like to see an IMAP extension where the client can upload and download password protected private keys. The security of the keys would rely on a strong passphrase (different from the IMAP passphrase obviously) but it would solve the problem of copying the keys between clients/backing them up. It would also mean that the clients can handle the key generation/management without the user even knowing it is happening. For #1 I'd like to see two options. First of all, the DNS solution described in the STEED proposal. Secondly, as a backup, if the DNS record doesn't exist, and somebody emails me with a header containing a link (*) to their key and its fingerprint, or even just the key it's self, I'd like to automatically use that. Initially major email providers like GMail/Hotmail wouldn't implement the DNS solution, but that wouldn't stop people using GMail/Hotmail with supporting IMAP clients from automatically looking up keys and encrypting. I can imagine these two solutions being implemented natively in Dovecot, Courier IMAP, Evolution and Thunderbird if the right people can be convinced. Maybe a few other widely used open source IMAP servers and MUAs. At that point, getting noticed by Microsoft/Google/Yahoo should be easier. Web browsers would need to be upgraded to make functions available for webmail providers. I'd imagine this coming later once average users are using encrypted email without even realising. Each new implementation would simply lead to more and more encrypted email. We don't need an all or nothing approach. We might even end up with MSAs that accept mail from clients without encryption support, then look up the recipients public key, and encrypt it before passing it on. (*) there's a nasty privacy issue when you're able to trigger a receiving email client to do arbitrary http lookups. It means the sender is able to determine when the recipient downloaded the email, and what IP address they were using at the time. Perhaps MTAs could look up the public key on delivery and add it to the email headers. If somebody pulls this off, the spam fighting industry is going to have a lot of fun. It becomes a lot more difficult to identify spammy content if you can't read it. I guess all of that filtering tech (bayes/uribl lookups etc) would end up having to be pushed to the client. Those are problems to be solved by other people though. -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
