Include full keys in keylists?

[milesmcc]

Should we provide an option to include the full ASCII-armored key in the keylist? It might make sense in some circumstances, and would give us another way to distance ourselves from keyserver infrastructure...

[nwalfield]

I'd like to second this.

First, requiring users to fetch keys from key servers exposes to the key server operator that they are subscribed to the keylist. This reveals meta-data, which is a privacy concern. But, it also gives the key server operator an opportunity to withhold data (e.g., revocation certificates, subkeys, etc.), which is a security concern.

Second, if the CA tsigns the keys (like OpenPGP CA does), most users won't get the signatures, because modern key servers like GPG Sync's default key server, https://keys.openpgp.org, don't currently distribute third-party signatures to avoid certificate flooding attacks.

Third, modern key servers like GPG Sync's default keyserver, https://keys.openpgp.org, don't distribute unverified user ids. Since the keylist admin can't verify the user ids, users need to be taught to verify their user ids. This increases the time until the key is actually available to other users. As GPG Sync's docs state:

For this reason, it's important that your authority key, as well as every key on your keylist, has a user ID that contains an email address and that all users must opt-in to allowing their email addresses on this keyserver. You can opt-in by uploading your public key here, requesting to verify each email address on it, and then clicking the links you receive in those verification emails.

Of course, most users will want their keys published on keys.openpgp.org so that their key can be found by people outside of their organization. But ensuring that the key is quickly available to people inside the organization is essential.

cc: @hko-s