-
-
Save anonymous/a665b156386773a9bdf7 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.