> Wake me up when they finally offer a scalable key management system. PGP always punted on key management, and as a result has been a perpetual market flop.
What is the alternative KM architecture in a distributed system? Remember that for e-mail there is no central authority to handle assigning keys to individuals, unless perhaps you want Gmail and Outlook.com to handle that.
The other e-mail security system is S/MIME (which uses X.509).
It's not hard to imagine a system where you can contact the server in the MX record for a domain over HTTPS (really just TLS) and query it for a specific email address to get the public key for that user.
Sure if someone knocks over TLS then your email encryption will be in trouble, but you will also have plenty of other problems at that point.
In a draft published in May of this year. This should have been a draft in the 90s.
It should have been in mail systems forever. Whenever you create an account the first email should have been the server sending you your private key in some format that every email client understands and would then prompt you to automatically install it in your client for that server.
Welcome to your new email account!
Your private key is attached in the standard format.
When your client asks you to install the key say "Yes", and allow it to automatically sign your email using that key for this account.
Don't forget to check the box to automatically encrypt mail when possible.
If email worked like this I bet secure POP and IMAP would have been implemented much faster than they were in real life.
Why not use the SRV record which has been created for this purpose, advertising seervices, specifically and use port 11371/tcp which has been registered with IANA for OpenPGP HTTP Keyserver? Why create new non standard mechanisms when these already exist? One could even use a different port and protocol with SRV records.
What if your mail server decides to advertise their public key instead of your public key, allowing them to read all of your email with you being none the wiser?
One way to solve this problem is Key Transparency, which aims to provides a mechanism to verify that you're receiving a legitimate key, somewhat analogous to Certificate Transparency.
We've implemented this at Proton: https://proton.me/support/key-transparency (although it's still in beta, and opt-in for now - but obviously the aim is to enable it by default).
Really paranoid folks could set up services online that check for this, but I kind of doubt it would happen very often because it would be a major stink for that email service if they were caught, and catching them isn't that hard.
The problem with existing keyservers is that there are several of them and you never know which one someone's public key might be living in. There may even be multiple potential keys for a single email address across the different servers. They are effectively useless for email encryption in their current form. It's a very rare email client that will even query the most popular ones looking for someone's key. In fact I don't know of a single email client that does.
What is the alternative KM architecture in a distributed system? Remember that for e-mail there is no central authority to handle assigning keys to individuals, unless perhaps you want Gmail and Outlook.com to handle that.
The other e-mail security system is S/MIME (which uses X.509).