
Keylist RFC: Distributing OpenPGP Keys with Signed Keylist Subscriptions - petethomas
https://tech.firstlook.media/keylist-rfc-explainer
======
Arubis
Feels reminiscent of the (seemingly defunct) Gossamer Spider Web of Trust:
[https://sites.google.com/a/gswot.org/gswot/resources/policy](https://sites.google.com/a/gswot.org/gswot/resources/policy)

Would be happy to see this succeed.

------
epoch_100
Author here. Feel free to ask me any questions.

~~~
AndyMcConachie
I just logged this issue in Github.

[https://github.com/firstlookmedia/keylist-
rfc](https://github.com/firstlookmedia/keylist-rfc)

It took me a while to figure out that the server has a list of key
fingerprints, yet you call it a KeyList. Perhaps call it a KeyFingerprintList.
In fact the document is confusing throughout in this respect. And maybe I'm
misunderstanding, but this is a mechanism for distributing fingerprints. This
is not a mechanism for distributing public keys. Right?

You define "KeyList" as a list of public keys in 1.2. But then in 2.2.5 you
state that the client should download the public key from a key server after
finding the fingerprint in the KeyList. Is a KeyList a list of public keys or
their fingerprints?

~~~
epoch_100
Thanks for bringing this up. I wonder how the naming conventions could be
improved? 1.2 does mention that this is a list of public keys identified by
fingerprints:

> 1.2 The term "keylist" is defined as a list of OpenPGP public keys
> identified by their fingerprints ...

Does this imply that the public keys themselves are included?

~~~
eximius
You could infer it describing a structure of { fingerprint : pubkey for keys
in etc }.

Just the name 'key list' implies a list of keys.

~~~
epoch_100
This makes sense. In revision 02, we will change the phrasing in section 1.2
to be something to the effect of "a list of public key fingerprints."

Thanks to you both for bringing this up.

------
exabrial
I want to solve a similar problem with my Maven pgp-signature-check-plugin
(checks artifact signatures). A federated list like that described was over
idea I had, another was registering keys in a blockchain.

~~~
Boulth
If you mean "federated" like DNS there is one interesting trick: if you
specify the signing key in gpg using email (e.g. gpg -u example@domain.com
--sign) GnuPG will insert the email as Signer's UID packet [0]. You can
inspect the signature using gpg --list-packets. Then when you verify the file
the key is downloaded using Web Key Directory, so basically over HTTPS from
the email's domain (in my example domain.com).

I'm thinking of using this to verify git signatures.

[0]:
[https://tools.ietf.org/html/rfc4880#section-5.2.3.22](https://tools.ietf.org/html/rfc4880#section-5.2.3.22)

------
sigjuice
Does the last bullet in section 2.2 mean that clients hang on to revoked keys?

~~~
epoch_100
Yes. In fact, we even recommend that the fingerprints of revoked keys stay on
the keylist for at least a few months to ensure that the key revocation is
sent to all subscribers. If you were to remove the key from the keylist, it
wouldn't be refreshed for the clients and therefore the clients may not know
it is revoked.

Holding on to revoked keys doesn't really present a security issue; because
most clients won't even let you encrypt a message to a revoked key, it would
be difficult for this to compromise security.

