Have you considered using Web Key Directory [0] for initial key lookup? Usually someone wants a key for a given email address (e.g. example@firstlook.media) and WKD solves just that. This is natively supported by GnuPG and some email clients (Enigmail in Thunderbird).
Do you use signatures and ownertrust so that the users' keys appear as "valid"? Or is that user's responsibility to sign the authority key and mark is as fully trusted?
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?
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?
Identity is established by the authority key. Let's say your workplace publishes a keylist that contains the PGP keys of all of your colleagues. Because each key on the keylist has been vetted by your organization to belong to its stated owner, you can trust it.
This is different from public key servers and revoke certificates because Keylists allow organizations to push new keys to all of their users—keys that the users might not have had before. Keyservers only provide a mechanism for retrieving keys you already know you want.
This is explained in detail in the post, if you're curious for more information.
There have historically been two competing models for how to establish the binding between a public key and its owner: the decentralized (web of trust) model[0], and the centralized (PKI) model[1].
This proposal seems to be an implementation of centralization (by delegating vetting authority to a central administrator) on top of the decentralized model. Meanwhile, there are already well-defined internet standards for how you could leverage the PKI model to achieve the same goals (X.500/LDAP for cert lookup and retrieval; PKI path validation for ensuring that a retrieved certificate has been vetted by a central authority; CRLs/OSCP for revocation).
This raises the question: why don't the existing internet standards that define the centralized model work for you? You allude to some of the answers:
(1.) Email clients that provide a smooth out of the box experience with LDAP+X.509+S/MIME are rare. Outlook + Exchange + Active Directory work really well for this in a properly configured domain, though introducing that stack comes with its own set of challenges.
(2.) Git integrates with PGP for its signature functionality. Of course, Git is itself a decentralized system; the architectures are aligned.
You also mention using PGP keys for SSH authentication, but note that using a GPG agent for SSH authentication doesn't actually rely on a PGP identity at all--it just uses plain asymmetric crypto with a key that happens to have a PGP identity associated with it. The model for distributing the public keys to the target SSH hosts is undefined.
On the other hand, I'd raise the following areas as places where a PKI-based cryptosystem would likely win out:
(1.) Certificate revocation/freshness concerns are handled very robustly by CRLs and OSCP. These standards have been thoroughly vetted and are in wide use across the internet. Meanwhile, the revocation/freshness model in Keylist is brand new.
(2.) PKI is already demonstrably useable at scale. I'm not sure the same is true for PGP. For example, how long will a Keylist update take in an organization with 100,000 users? Also, how do the various GPG client implementations perform under these conditions?
I think your proposal would be stronger if it contemplated these issues head-on.
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.
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.
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.
Would be happy to see this succeed.