On Wed, Sep 17, 2014 at 9:43 AM, Henry Augustus Chamberlain <henryaugustuschamberlain@gmail.com> wrote:
I propose that we use the local part of the email address to store the public key, ... my email address would be (64 random letters)@gmail.com ... Somebody not using encrypted emails could still click on your "mailto" link and send you an email, although it will be unencrypted
Putting keys into some_encoding@example.com might cover some bases related to offline key lookup and message validation. Most user and system mail tools would need changes to handle string width and keytype, addressbooks updated, etc. Totally burying OpenPGP, passphrase and key lookup/use behind a fully integrated MUA GUI for grandma would work just as similarly well right now today with no such encoding. But in the end, all you're doing is covering the message body, and in today's world that's clearly not enough. No one's yet solving the huge issues with leaving mail exposed to what is essentially open-for-all-to-inspect central storage and mail routing. The "who's IP talking to who", "From To Subject, daemon headers, etc" metadata, when, how much/often, provider logs, someone sending you unencrypted mail, you giving up your private keys to the provider or running blobs they provide to you, etc. This is all unfixable with traditional "Email" models. This is why that to really solve anything more than the message body, you need to go completely nextgen and turn that 'email address' into an anonymous P2P overlay network node address, run your overlay client [which supplies a mail/messaging front end] and send/receive mail through that from/to your usual MTA/MUA/messaging toolchain. The real work there is in pushing the P2P node count up... - Research how many users globally might leave their messaging node up 24x7 for a direct realtime overlay connection with the far end "user@node"... 1/10/100/n*1000 million? - Develop message storage [and forward/poll/expiry] within the overlay for those that aren't in online mode. - Determine any hardware limitations and thin client models. There is an ongoing thread with the subject "The next gen P2P secure email solution" that contains various people's initial thoughts/framework on this.