5 ms·

Author here. Feel free to ask me any questions.

asimpletune 8y ago
Can you elaborate as to how identity is established? Also, how is this different from public key servers + revoke certificates? Interesting post, thanks!
- epoch_100 8y ago
  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.
Boulth 8y ago
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). [0]: https://wiki.gnupg.org/WKD https://wiki.gnupg.org/WKD 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?
AndyMcConachie 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.
bdhess 8y ago
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

Can you elaborate as to how identity is established? Also, how is this different from public key servers + revoke certificates? Interesting post, thanks!

epoch_100 8y ago
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.

Boulth 8y ago

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). [0]: https://wiki.gnupg.org/WKD https://wiki.gnupg.org/WKD 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?

AndyMcConachie 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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.

bdhess 8y ago

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