Page MenuHome GnuPG

Allow embedding preferred keyserver URL in signatures
Open, NormalPublic

Description

For the PGP web of trust to actually function, it is vital that those verifying a signature are able to see the public key used. The issues with public keyserver pools are well-documented, and rather than simply hoping that the verifier checks a keyserver you've uploaded a key to, it is sensible to embed the keyserver of your choosing in a signature.

This has the potential to reduce the centralization of the ecosystem considerably, as you can specify a URL on a domain you control as the "canonical" copy of your public key. Even if the reader does not turn honor-keyserver-urls on, they can still manually retrieve the public key at their discretion.

At the moment, there is a serious issue with using sig-keyserver-url by default: you must provide the URL in question. While the substitution options can be useful for working with multiple keys, it would be much easier if users could simply embed the preferred keyserver URL of the primary key used to make a signature. This could be implemented simply by adding a new %-expando.

As an example, consider the following scenario: a user has a primary key for personal use, and a primary key for work. Each have distinct UIDs and signing keys that are used to sign Git commits in their respective roles. The work key has an ultimately-trusted signature from the primary key, so anyone who trusts the first key for personal use should be able to trust the second key for work use. However, with just a Git repository with commits signed for work, that hypothetical observer would have no way of knowing this beyond hoping they stumble across the key in a common keyserver.

By embedding the preferred keyserver URL of each key used, the problem is solved: git log --show-signature will show where to get the public key used for work, which will contain the signature from the personal primary key, which allows the commits to be trusted.

Event Timeline

Saklad5 created this object in space S1 Public.
Saklad5 created this object with edit policy "Task Author".
Saklad5 changed the edit policy from "Task Author" to "All Users".Jun 23 2022, 1:18 AM
Saklad5 renamed this task from Allow embedding default keyserver URL in signatures to Allow embedding preferred keyserver URL in signatures.Jun 24 2022, 1:37 AM

I don't see why this is a child task of T6020: the features are similar, but they don't actually impact each other in any way.

I suspect my original name for the task is partially to blame for that.

This is a reasonable feature, however it should be noted that this implies a fairly large metadata leak: You are essentially adding a URI to signatures that will be pinged on signature verification.

This also relates to T6020, which encourages certificate-specific keyserver URIs.

This is a reasonable feature, however it should be noted that this implies a fairly large metadata leak: You are essentially adding a URI to signatures that will be pinged on signature verification.

Not really. At least, not additionally to what already happens. If you explicitly enable auto-key-retrieve and honor-keyserver-url, which are both disabled by default, then gpg will try to look up the key on the specified keyserver. Moreover, via the option --sig-keyserver-url it is already possible to "specify the preferred keyserver for data signatures".

If I understand correctly, this feature request is about making it possible to automatically specify the key's preferred keyserver as preferred keyserver for data signatures when signing data (e.g. git commits) which is just a tiny extension to the already existing sig-keyserver-url option and doesn't add any "metadata leaks" that do not already exist today.

I suppose you're right, we might have crossed that bridge a while ago. Simple availability of certificate- or even signature-specific keyserver URIs just make the risks of honor-keyserver-url more obvious than before.

I suppose you're right, we might have crossed that bridge a while ago. Simple availability of certificate- or even signature-specific keyserver URIs just make the risks of honor-keyserver-url more obvious than before.

Personally, I consider that risk somewhat overblown. I understand why it isn't on by default, but frankly you could accomplish the same thing trivially by embedding images in HTML. In fact, people do.

Since it isn't on by default, there is absolutely no risk. The user has to opt into automatically retrieving keys and honoring the keyserver URL. WKD only requires the first opt-in, despite doing the same thing. In fact, my preferred keyserver URLs use the same hostname as WKD!

As for using specific sources, that's how OpenPGP is supposed to work. Public keyservers are a crude alternative that relies too much on trusting volunteers to keep servers operational (and trustworthy). It's much simpler and effective to provide the public key directly for evaluation, and this allows you to do so without embedding your whole public key everywhere.

Besides, I trust that anyone who wants to hide their IP address has the good sense to use Tor. I'm certainly not going to stop them from doing so.