Discussion/half baked idea: safely looking up PGP keys automatically

[exabrial]

So one of the things that keeps us from going 100% in on PGP checking is the sheer volume of keys we'd have to pin in the keyfile.

Have you seen keybase.io? It's like a fancy PGP keyserver, but it also allows you to bind a PGP key to a Github account and email address, pretty cool. Basically, a user publishes a pgp signed manifest as Gist on github and keybase gives you a way to verify that proof.

They do something cool too: everything that happens in your account it's put into the Bitcoin blockchain. What if we did something similar? We wouldn't have to the crypto work by hand, keybase has an API for new proof integrations: https://keybase.io/docs/proof_integration_guide

An author could sign up to bind a maven artifact to a PGP key. We'd have them publish a "proof" to maven central showing they can publish signed test to a artifact namespace.

Then when the plugin encounters an unknown signature, it could see if a proof exists in keybase. We could then verify the proof and pin the key automatically locally.

[cobratbq]

Let me rephrase your points to check if we're on the same page:

1. for large projects, there are many mapping entries to put into the keys map. (This would be a one-time action. Afterwards you update the file with the changes in dependencies/plugins.)
2. every user of PGPVerify is doing the same thing in maintaining his keys map. If an open, global solution is offered, e.g. blockchain as a registry, anyone can use it with little effort on their side. (Though this solution hints at something "on-line"-based.)
3. with a global solution, i.e. you use an existing keys map, you already have one other confirmation of expected signatures, which is the person that added this particular entry to the keys map. That is, assuming they added the valid public key.

I'm just going to iterate on your idea, as I'm not the author of the plug-in. Here's my 2 cents.

1. This is a one-time action, so even with 2000 entries to add, you only need to do this once. However, it would be nice if you could just copy/use an existing keys map.
2. Given that we mostly all get our packages from the same global artifact repositories, anyone composing such a keys map would come up with roughly the same outcome. (We should all have the same public keys for equal artifact entries.)
3. Given that we expect equal entries, using an existing keys map gives you one confirmation of consensus for free.

Personally, I think a blockchain would be overkill. I can imagine, though, to have a separate maven repository for maintaining a public list. For example, @slawekjaranowski could host one, such that it lives near to original source code. (It is not my intention to put him into this position, just to give an example of where such a repository might live.)

The benefits I see:

• easily manageable, both on-line and off-line, given the capabilities of git. Off-line could be as easy as copying the file into your project.
• for "fast-moving" projects, could be added as a submodule to the project and updated together with the project.
• as multiple projects would be sharing the same keys map, any one user can identify public key mismatches. Other users of the repository can verify.
• as we can trivially verify the keys map by adding a pom.xml file with the exact dependency, we can run verification whenever the keys map is updated. So the property of mutually distrusting participants as facilitated by blockchain technology is not strictly needed.

@slawekjaranowski what do you think?

[exabrial]

you: on points 1, 2, 3

Precisely. A keymap is would be a federated list... you obtain it from a trusted party and verify artifacts against the keymap. We could do that now with a git repo with common artifacts and signed commits by a trusted party (which would work and be pretty cool). The downside of this is there is a registration/signup/verification process with the authority; while not terrible, it would be cool if the verification step were automatic.

"blockchain would be overkill"

Yes, there's no reason to re-invent this, especially when Keybase has a toolkit to do this already.

The cool part about the Keybase is that an author publishes a "proof" they control an account (sorta like putting a TXT record in DNS to prove you control a domain, or my github gist here: https://gist.github.com/exabrial/a0ffe65b8ee007645dda): A client can securely discover the correct key for an artifact even if they've never seen before by looking up the proof, then checking the proof signature.

These two approaches aren't mutually exclusive. We could have a git repo with signed commits that has pinned keys for artifacts, and the commit signer is a trusted party. We could also have a Keybase proof integration that allows people to prove they control a namespace on maven central, and bind a pgp key to that namespace.

[cobratbq]

Precisely. A keymap is would be a federated list... you obtain it from a trusted party and verify artifacts against the keymap. We could do that now with a git repo with common artifacts and signed commits by a trusted party (which would work and be pretty cool). The downside of this is there is a registration/signup/verification process with the authority; while not terrible, it would be cool if the verification step were automatic.

Agree. I'm wondering if we can make this automatic. Or at least mostly automatic. The entries that are added to the key map, can simultaneously be tested by adding a dependency on an artifact like the entry added to the keys map. The tricky thing is verifying that all entries are indeed also added as dependency.

The cool part about the Keybase is that an author publishes a "proof" they control an account (sorta like putting a TXT record in DNS to prove you control a domain, or my github gist here: https://gist.github.com/exabrial/a0ffe65b8ee007645dda): A client can securely discover the correct key for an artifact even if they've never seen before by looking up the proof, then checking the proof signature.

I am sort-of seeing where you're going with this, though one thing eludes me. How do you match an artifact to an author? The only option that I see is to match by maven groupId, so keybase would need to record the maven groupId for an account. However, there are already violations of this, e.g. org.apache.maven.plugins contains many artifacts, not all of them signed with the same key.
So how do you see this? (By the way, I do have some knowledge of keybase.io. It's mostly how to apply it in this case, that I'm still struggling with.)

These two approaches aren't mutually exclusive. We could have a git repo with signed commits that has pinned keys for artifacts, and the commit signer is a trusted party. We could also have a Keybase proof integration that allows people to prove they control a namespace on maven central, and bind a pgp key to that namespace.

Agree. And I also see this as a valid extension to the repository. I, personally, am just a bit hestitant to pull in blockchain for everything if it isn't strictly needed. I'm now trying to convince myself that there isn't a simpler way to accomplish the same thing.
I'm not sure if we require the commit-signer to be a trusted party. The only extra requirement, AFAICT, is that we can verify that we have a test case for the changed entry in the keys map, such that a github action or a build action can confirm that the key corresponds to the artifact signature. Am I missing something?

[exabrial]

The only option that I see is to match by maven groupId, so keybase would need to record the maven groupId for an account

Which isn't a bad thing necessarily. Having a single key sign for a group is probably the right way to do things. But, I don't see why a key proof couldn't be published in an artifact subdirectory as well

[cobratbq]

Which isn't a bad thing necessarily. Having a single key sign for a group is probably the right way to do things. But, I don't see why a key proof couldn't be published in an artifact subdirectory as well

Let's see if I understand what you're suggesting:

1. publish a proof-of-ownership for maven artifacts in a maven repository.
2. proofs can be either per group (groupID) or per individual artifacts (artifactID).

What I don't quite understand is how to work with this: Let's say I have retrieved an artifact. I find a signature on it and need to verify this.
Is your suggestion: take the key ID, look up the key in the (keybase.io) registry, then check if there is a maven artifact groupID or artifactID registered for this account? If so, this is confirmation that the account owner also manages this groupID. Correct? But if it isn't, you cannot derive from that, that the key ID is illegal, as the owner could simply not have registered. So what actionable information can I derive from this then?

[Update: Alternatively, we can look up the maven groupId/artifactId and find the registered account's PGP key ID it correlates to. Then at least, you know if we're expecting the same key ID as we find on the signature. That would be acknowledgement of ownership, so I guess this is what you had in mind.]

Tangentially, some questions that came up:

• How to act if ownership changes given a certain version of the artifact? (and group, which is basically equivalent to a change of ownership for all artifacts in that group)
• What if account owner forgot to update his registry proof-of-ownership when getting a new key ID. Nevermind. Guided by keybase.io IIRC. Although the user could simply ignore this and not re-prove ownership after the PGP key change.

Anyways, I'm trying to outline the mechanism you seem to have in mind, as I don't quite grok it yet. I think. I'm trying to figure out how introducing keybase.io (or any registry) into the mix provides more certainty/security than without.

Update: I missed your link to the keybase.io proof integration guide. I'll have a look at it later.

[slawekjaranowski]

I think that making decision if key is valid for given artifact, using yet another registry will not work. If it is not global requirement we don't have any guarantee, that every owner of artifacts will publish such information.

Process like you try describe should be part of requirements of maven central rules, like: https://maven.apache.org/repository/guide-central-repository-upload.html.

But I think that we can start try build map artifacts to pgp key, I can prepare some project with automatically testing given map.

[exabrial]

I appreciate everyone's engagement in this idea :)

Process like you try describe should be part of requirements of maven central rules

You're exactly correct. Unfortunately it's not. That's (one of the reasons) why this plugin exists though, otherwise as long as everything was transferred by TLS from maven central, we wouldn't care.

I think that making decision if key is valid for given artifact, using yet another registry will not work. If it is not global requirement we don't have any guarantee, that every owner of artifacts will publish such information.

I'd advise to not let perfection impede progress. Keybase is just a key discovery mechanism that links a pgp key to online identified like github, hacker news, facebook, a bitcoin address etc. The idea here is to allow a link to maven central as well. Using the keybase method to discover pgp keys is not mutually exclusive from using a local keymap, which theoretically could be supplied by a trusted third party.

[slawekjaranowski]

So I create project - https://github.com/s4u/pgp-keys-map
We can start to populate pgp keys

[slawekjaranowski]

I hope that issue #84 can help to trace which pgp is used for specific artifacts.