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]

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. [0] https://en.wikipedia.org/wiki/Web_of_trust https://en.wikipedia.org/wiki/Web_of_trust [1] https://en.wikipedia.org/wiki/Public_key_infrastructure https://en.wikipedia.org/wiki/Public_key_infrastructure