A Rubygems trust proposal

Proposal

Here's the basic premises: invent as little cryptography as you can.  Make the tools as simple as possible.

Here's the proposal: use PGP for agent authentication, use git for verification distribution.

The kernel of the idea is this: in a public git repo, any user can create file(s) that are a list of tuples of the form:
{domain,object identifier,public identity,signature}

When I release a gem, I sign it, and add
rubygems mygem-x.y.z [email protected] {signature}

to my verifications repo.

When you want to install the gem, you can pull the file from rubygems.org (gem fetch mygem-x.y.z), and use OpenPGP to validate *a* signature on the gem.  Then based on the validation, you can gem install <directory>/mygem-x.y.z.gem or not.

Q: Where do you look for signatures?
A: In your personal verification repo, and the submodules you've added that point to well-known (to you) maintainers of signature lists.

Q: Who's signatures do you trust?
A: Basically, punting that to the PGP WoT.  There's a bunch of infrastructure built up there, already.  If a gem is only signed by people not in your WoT, you know who to start looking for.  I'd expect the community to start building a solid web pretty quickly - there'd likely be a rubygems.org key who's key-signature would be a low-security pro-forma way to add new developers to distribution, and whose trust could be revoked if gems were found to be malicious.  (That is: rubygems.org would be a "first-signer" on new dev keys, as well as a second-signer on gems.  "Only two signatures" might be a warning for installation.)

Q: Principle of least access?
A: A deployment would have it's own key, used to sign gems that are part of the deployment, or the keys of trusted gem authors.  The deployer could sign the key and use his own public key as the deployment's trust basis.  If you ever doubt the security of a deployment, revoke your signature of the deployment's key, and and operations that check gem authenticity now fail.

Q: Toolchain?
A: On the one hand, openpgp, git, awk and grep (+ curl or gem fetch) probably can do all this, manually.  Which is important, since it means that if we don't trust our tools, we have fallbacks.  On the other hand, it'd be nice if `gem push` `gem install` and `bundle update` could handle all the rigmarole for the day to day.  Given that we're basically just wrapping up some shell commands, that shouldn't be very difficult.

Q: What about non-adoption?
A: One nice feature here is that even a userbase of one could make use of this system - simply reviewing and signing everything she wanted to use herself.  Greater adoption means that it's less onerous to do the reviews, since one trusted reviewer (or trusted author) is enough for everyone who trusts them to do the install, but that's not required.

Q: Why the "domain" in the tuple?
A: Because it seems to me that there's a lot of security value in not tying this closely to the existing Rubygems infrastructure (regardless of how secure that is.)  If it's well decoupled though, there's no reason the system couldn't be extended to provide authenticity for non-rubygems deployments - even as simple as tar xzf; configure; make; make install style ones.  

Q: Refinements?
A: It might be nice to decide what to do in the event of conflicting signatures (i.e. of the five people who've signed this gem, we trust 3, but only 2 of their signatures are valid) - in my opinion, that might be the dial for "High" versus "Low" security - in High, one invalid trusted signature is enough to reject the gem.  In Low, maybe the signature is old?

Q: Wouldn't monotone be a better choice for the signature distribution platform?
A: What, because of the existing cryptographic chain of trust in monotone commits?  (http://monotone.ca)  Yeah, maybe it would.  (sigh)