
How to setup your own WKD server - stargrave
https://shibumi.dev/posts/how-to-setup-your-own-wkd-server/
======
tptacek
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.

~~~
alex_young
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.

~~~
alwillis
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/](https://slxh.nl/blog/2016/pgp-and-
dns/)

~~~
tptacek
PGP and DNS. A secure messaging system tied to a PKI controlled by world
governments. What could possibly go wrong?

~~~
alwillis
From [https://easydns.com/blog/2015/08/06/for-
dnssec/](https://easydns.com/blog/2015/08/06/for-dnssec/)

 _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._

~~~
tptacek
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.

~~~
alwillis
_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.

RFC 4398: [https://www.rfc-editor.org/info/rfc4398](https://www.rfc-
editor.org/info/rfc4398)

RFC 7929: [https://www.rfc-editor.org/info/rfc7929](https://www.rfc-
editor.org/info/rfc7929)

~~~
tptacek
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.

~~~
Boulth
A different line of arguing may be helpful: not even GnuPG validates DNSSEC
signatures (source: [https://dev.gnupg.org/T4618](https://dev.gnupg.org/T4618)
). That's why DNS key discovery schemes are not enabled by default there (WKD
is).

~~~
alwillis
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.

