crit.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?

1. Already a problem in the current rubygems.org setup.
2. Revoke the CA cert, all gems are now invalid. Rubygems maintainers issue a new CA cert on a new CA infrastructure, install a new pubkey on the rubygems.org infrastructure, instruct gem authors to obtain new keys, re-sign and upload their gems. Users must install the new root certificate. This is a ton of work, but it's also a worst case scenario, and is why the signing server is limited to as small an attack service as possible.
3. Key backups or redundant CA hosts would be good. Obviously care must be taken to ensure that duplication of these systems doesn't leave one open to compromise due to lack of maintenance.
4. Issue a new key, same as step 2.
5. I'd argue it's no more complex than the existing infrastructure - just more of it. Definite concern, though.