On Wed, Jan 19, 2005 at 03:54:33AM +0100, Andrej Kacian wrote: > Well, I for one am really curious about how will this "web of trust" > issue be solved. Some devs simply can't afford to go to the events > where devs usually meet, be it time constraints, or simply a money > issue. I've been playing with an idea about this for a while.
As for conventional webs of trust, I strongly encourge every developer to meet up with other Gentoo developers, or other people that are very active in open source development and use GPG keys. The Debian developers are probably one of the best groups to look for on this (they exist on every continent http://www.debian.org/devel/developers.loc). I've personally met up with 6 debian developers, and thru them I'm linked to most of the core Gentoo developers, and a great many other folks (Linus is 5 keys away). The following is NOT intended as a standalone solution, but instead to augment conventional webs of trust, and help out developers that are unable to meet up with others. Also, it makes it much easier to for users to verify sets of keys. At a minimum level, the goal is to ensure that we can tie together: - @gentoo.org email address (actually, wherever it forwards to) - CVS access / SSH key - GPG key Thus we can develop an identity for a developer. To convincingly steal an identity, an attacker would need to get access to both the developers SSH key (via his passphrase or other means), and his GPG key (as with SSH key). This really isn't hard, but it does raise the bar for the attacker. Alice = Admin (NOT Devrel, see [1]) Bob = developer being authenticated. Basic process: 1. Alice generates a secret, and signs it with GPG. 2. Alice stores a private copy of signed secret. 3. Signed secret is encrypted with Bob's GPG key. 4. Encrypted,Signed secret is sent to [EMAIL PROTECTED] 5. Bob decrypts the message. 6. Bob signs the decrypted message. 7. Bob commits the signed, decrypted message to CVS (Using his SSH key). 8. Alice checks the message in CVS to see if the original secret matches what she stored, and that her signature is intact. At this point, Alice has tied together Bob's identity by the elements described above. Now Alice can sign Bob's key, to indicate she has a modicum of trust Bob. Now if several independant (perhaps geographically independant, but they just need to be independantly trustworthy to make it hard for them to co-ordinate an attack) Alice entities all do the above process with Bob, you have established several trust sets. The group of Admins should be connected via multiple existing physical webs of trust (preferably more than one, to help verification). This is easily accomplished by meeting up, and also seeking other open source devs as noted above. Lastly, we make a special signing key, whose sole purpose is to bind the Admin keys together directly for verification of Gentoo-specific keys. The signing key should be cross-signed by all Admins [2]. Now we construct a keyring to distribute to users, consisting of all developer keys, the admins keys and the master signing key. To verify some signed data now, portage runs with just the above keyring, and marks that it ultimately trusts the master signing key. This process does NOT mitigate dangers, but instead aids only trust networks, and allows easy verification of packages. [1] It's important that Devrel and the Admin are not the same person, and are reasonably independant, as otherwise Devrel could subvert the process, since they are the ones that set up the email address and SSH key in the first place. Alternatively somebody in devrel could be one of the admins, but the number of non-devrel admins must be larger than the number of devrel folk (to avoid the byzantine generals problem). [2] I haven't solved who should be in charge of the master signing key, but this should not too much a problem, I'm thinking that the trustees might be the best place to put this. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpsRtQMCrPDz.pgp
Description: PGP signature
