What alternatives exist for exchanging public keys with another person for sending email, except the obvious way of manually pasting the public key into an email saying, "Here is my public key"?

  1. Do email clients who support encryption usually fetch the keys from key servers automatically (based on the other person's email address) so you don't even have to think about it?
  2. If one doesn't use key servers, do email clients have a built-in method of exchanging public keys without human intervention, except possibly clicking "OK" to accept the exchange?
  • Are you asking for standards or client specific implementations? And are you asking about PGP or S/MIME or both? May 6, 2018 at 6:31
  • @SteffenUllrich: Either a defined standard or something that is very commonly available. Preferably PGP, but S/MIME too if they have something smart up their sleeve.
    – forthrin
    May 6, 2018 at 6:35

1 Answer 1


As this is asked on Information Security, it's crucial to first concentrate on how the keys should be trusted. Unlike SSL PKI with certificate authorities (CA), PGP is based on a web of trust. Anyone could send you an email with a self signed PGP public key, claiming it's really the key of the sender. It's as easy to spoof as the email itself. The responsibility of accepting and trusting it is on recipients side. Building such feature to email clients would create false sense of security.

Retrieving keys directly from key servers sounds like a bit better idea, but it doesn't actually give any guarantee, either. Anyone can send keys and signatures to the key servers and it's better to manually check who else trusts the unknown key, unless you can't check from independent source that the fingerprint matches. The keys would be retrieved using a keyring management software instead of the email client; e.g. the Kleopatra certificate manager and GUI for GnuPG a built-in functionality for this.

Best method for validating a key would be to ask personally, but I'd publish the key on a CA signed TLS protected web site, possibly with a DNSSEC signed IP address. This way your key would be behind two independent public key infrastructures (SSL + DNSSEC), making the source quite trustworthy regardless who have signed your key and could the recipient trust your web of trust.

For example, many national computer emergency response teams (CERT) publish their PGP keys on their HTTPS websites, and some are properly signed with DNSSEC, too:

There is an experimental RFC 7929 for DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP from 2016, introducing a new DNS Resource Record (RR) type, OPENPGPKEY. This would be easy to automate on an email client. However, the RFC 7929 itself notice the problems with the security of this approach (section 7.6):

Anyone who can obtain a DNSSEC private key of a domain name via coercion, theft, or brute-force calculations, can replace any OPENPGPKEY record in that zone and all of the delegated child zones. Any future messages encrypted with the malicious OpenPGP key could then be read.

Therefore, an OpenPGP key obtained via a DNSSEC-validated OPENPGPKEY record can only be trusted as much as the DNS domain can be trusted, and is no substitute for in-person OpenPGP key verification or additional OpenPGP verification via "web of trust" signatures present on the OpenPGP in question.

  • Thanks for sharing thoughtful advice. But to be practical here, are you saying that unless you use the maximum secure method available for key exchange (SSL + DNSSEC or similar/better approaches), email encryption is useless and false security, because it can so easily be forged?
    – forthrin
    May 6, 2018 at 15:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .