crit2.txt

Critique of CA/Root-key proposal

1. Premise: First come, first serve. The scheme assumes that e.g. 37signals will be the first
   to register their rails-gem. For less popular gems a malicous party MAY snatch up the id
   before the legit author gets around to it. (Possible mitigation: Captcha?)
   
2. Single point of failure: Signing server gets compromised, all gems are now compromised.
    Recovery path?
  
3. Single point of failure: Signing server is down. No new gems/authors can be registered.
    Availability?   Keeping the key safe across a cluster of hosts?
    
4. Single point of failure: Signing key is lost. Recovery path?  See #2

5. SPOF: Longterm maintenance. System is complex, will the volunteers be able to fix it
    one year down the road?


Basic concerns:

* What does the centralization gain over a Web-of-trust approach? 
  Continuity (verifying that an update for a gem was signed with the same cert as the
  previous version) can be achieved in both approaches. The initial verification ("should this gem
  be trusted") doesn't seem much different either, as the signature from rubygems.org doesn't
  convey whether the code is trustworthy.

* Couldn't similar properties be achieved by sending (gem_name,fingerproint) upon verification
  to a set of independent scoring servers in a Web-of-Trust approach?
  That's again a first-come-first-reserve issue, but without the single point of failure of a CA.

1. Existing gems have the author's email address in the gemspec already. I would guess that the signing process would require verification from that email address, and that email address in the certificate used for signing. That way someone trying to "get in first" on a gem would have to compromise the author's mail account.

In general, I think the single point of failure of a centralised server is bad.

What if the gems were signed by the authors themselves using a certificate from the signing server that grants them the right to sign gems for a period of time. (Similar to Apple's developer certificates) where they are issued against from a root certificate, (and can be revoked too). The (only thing?) the signing server would need to do is issue the developer's certificates which they use to sign the gems themselves.

Using this model, developers could still sign gems even if the main signing server was down. The only time it would be a pain is if the developer certificate expired and he/she wanted a new one at the time signing server was down.