[austincheney]

The keys don’t come from the servers but from the end users, so the remote server won’t have the remote user’s key.

> Or they could let their provider hold onto a copy of the private key

Then the key is no longer private. The idea of a private key is not to share or distribute it.

[Shendare]

Why can't somewhere.com have the public key for [e-mail] and serve it to other e-mail providers on request?

Letting one's provider hold onto the private key doesn't provide the same level of security as the user being the only one with it, but it's a helluva lot better than not bothering with encryption at all.

Private keys can also be protected with a password, right? So the provider could have a copy of the private key but not the password to utilize it. The user would just have to never forget the password as opposed to never losing their private key to a hard drive failure or whatever.

[austincheney]

> Why can't somewhere.com have the public key for [e-mail] and serve it to other e-mail providers on request?

They could, but then somebody would have to deliberately request it. That would also mean adding a separate transmission/protocol different from the email protocols routing the messaging. That is a more streamlined process, but still not fully automated.

The only way to ensure adoption is to force onto users as an automated check of the primary protocol like the handshake of TCP. Even then you should still have to account for SPAM and anonymous users you don't want to exchange keys with.

Yes, private keys can be issued with a password. That is not an excuse to disperse your private keys though, because that password can be brute forced and then a criminal can access any account using that key set provided they aren't further blocked by something like 2 factor authentication. The password is just there as added security for things unintentional disclosure or unintended access, but not as a primary means of security.