Why would you ever do this? Public ledgers of long-lived identity keys are an anti-pattern. They beg people to retain a single key, across all their devices, whose compromise is catastrophic.
Who said the keys need to be long lived in WKD? WKD just makes the key discovery easier based on email address, you can rotate your key as often as you want (just set the expiry date so clients check it).
Also, I'm not sure if I get the "public ledger" part as WKD I just your own HTTPS server. It doesn't have anything in common with keyservers.
Forgive my curiosity, but what is a better solution?
It seems like the alternative is delegating control of your identity to a central authority, which greatly increases the risk of compromise of many users all at once.
Perhaps there's a third option I'm not considering.
There are more options, including using the domain name system, preferably using DNSSEC to securely sign the DNS resource records: https://slxh.nl/blog/2016/pgp-and-dns/
The “government controlled PKI” criticism ignores the fact that traditional TLDs are a government controlled naming system. This is much worse than a government controlled PKI…
The only way to escape governmental control is to use overlay networks, like Tor, and non-traditional TLDs, such as .bit and .p2p. But even if you choose a domain with a TLD that isn’t controlled by a government, you still need DNSSEC to securely delegate to a nameserver and to communicate application level cryptographic information.
That is an argument - a bad, wrong one - in favor of DNSSEC over the WebPKI CA system. But PGP doesn't use the WebPKI either. DNSSEC makes even less sense here. No reasonable person would ever use DNSSEC to protect end-user PGP keys; that design would be incompetent on its face.
No reasonable person would ever use DNSSEC to protect end-user PGP keys; that design would be incompetent on its face.
Don’t get it twisted.
Nobody suggested protecting end-user PGP keys with DNSSEC.
Because DNSSEC ensures the integrity of DNS records, a user that publishes their public key in the DNS using a CERT or PKA record (both defined in RFC 4398) or uses an OPENPGPKEY record as defined in RFC 7929, can be sure anyone who uses a DNSSEC-aware resolver (Google's 8.8.8.8, Cloudflare’s 1.1.1.1, Quad9’s 9.9.9.9) can confirm the integrity of these records.
Exporting public keys to be published in the DNS has been supported by GnuPG for at least 10 years.
Without DNSSEC, there’s no way to ensure the DNS records haven’t been tampered with. That seems particularly important for public keys.
You just said the same thing you said previously with more words and a bunch of RFC cites. If you store your PGP key in the DNS, then the entities that control the DNS can control your key. That they are "public keys" is immaterial; the point of a public key stored in a public ledger is that other people can rely on that key to safely send you a message, which they clearly cannot do with a key stored in the DNS.
Even if you believed DNSSEC is a good system --- nobody should; it's bad, and moribund --- a secure messaging system with end-user keys anchored in DNSSEC-protected records would be an incompetent design, on its face, simply due to the basic core architecture of the DNS and DNSSEC.
A different line of arguing may be helpful: not even GnuPG validates DNSSEC signatures (source: https://dev.gnupg.org/T4618 ). That's why DNS key discovery schemes are not enabled by default there (WKD is).
It’s not the job of GnuPG to validate DNSSEC signatures; that’s what a DNSSEC-aware resolver like BIND, Unbound or Knot does. If you’re not using such a resolver, all bets are off regarding trusting anything in the DNS.
But it’s certainly easy enough for GnuPG to check the DNS flags to verify the resolver has validated the DNSSEC signatures, therefore authenticating the openpgp record for its use, which is the point.
This is how DANE records work; SSH doesn’t validate DNSSEC signatures either but that doesn’t stop it from using SSHFP records in the DNS when they’ve been signed.
If you store your PGP key in the DNS, then the entities that control the DNS can control your key.
As for the trope of DNSSEC being a government controlled PKI, I can’t help you with that.
The beauty of DNSSEC is its flexibility. For the paranoid, a zone operator using DNSSEC only has to trust themselves and nobody else by creating their own trust anchor.
And of course, I control they keys and when they rollover, etc.
But even under normal conditions, where you trust the root key and the chain of trust from it, nobody—not even the government—is going to break my ECC keys before they get rolled over.
