Ben Reser wrote:
>On Wed, Mar 17, 2004 at 10:04:01AM -0800, Justin Erenkrantz wrote:
>
>
>>FWIW, over in httpd-land, each RM signs the key with their own personal
>>key. However, those keys are signed by almost everyone else in the project
>>and we hold key-signing events at most conferences. The point of the key
>>is to have it verified with the individual end-users (i.e. a path in the
>>web of trust from the RM to the end-user), not whether it verifies
>>successfully.
>>
>>
>
>That's one way of looking at it. But ultimately our goal is to create a
>way to verify the tarball that is as secure and as painless for the end
>user as possible. Many people that will be using our software have not
>participated in the web of trust or do not have a path to our
>contributors. Do we really expect people to organize a key signing
>party in order to authenticate and install our software?
>
>However, providing a project key signature is not mutually exclusive
>with individual signatures. We can do both. If everyone who wants to
>sign a release produces an ascii armored key you can just cat the
>signatures together into one file.
>
>
>
>>Having a 'shared' key presents some security challenges in trying to keep
>>it safe from compromise. And, how do you verify that key - it's a group
>>key not tied to a person?
>>
>>
>
>The same way you verify a md5sum. You download the key and then obtain
>fingerprints from multiple sources. E.G. the website, tha mailing list,
>asking people on IRC, etc...
>
>But really the problem is no different if you use individual keys. Sure
>you can verify that the individual is who they say they are. But can
>you verify that they are authorized to do a release? What if someone
>hacks into Joe Well-Connected and steals his private key, manages to
>figure out his password. Then they break into our webserver. Modify
>the list of the people who are authorized to sign releases. And does a
>release?
>
>Signing with individual keys does not eliminate the verification
>problem.
>
>
>
>> Whomever needs to create a release needs that key to sign with...
>> This is predicated on the hope that we'll move to a rotating RM in
>> the future. We're not there yet because the process isn't there yet.
>>
>>
>
>Not necessarily. We can create our own web of trust. One person can
>have the project key and can sign the tarball with the project key after
>verifying the RM's individual signature, verify MD5 sums, etc...
>
>
>
>>Personally, I'd vote for just having the RM sign it with their personal key
>>and increasing the number of signatures on all of the RM's keys.
>>
>>
>
>It's not really a one way or other issue. We can and should do both
>things.
>
>Here's how I see things working. I'd written a long email describing
>this that I hadn't finished up on but I'll give you a brief snippet of
>what I was thinking:
>
>A project key is generated. Signed by the people in Chicago. As
>developers have an opportunity to get togther they can do signings of
>each others keys. In the meantime we can bootstrap our web of trust off
>Debian or Apache developers who are usually well connected and spread
>all over the world.
>
>When a release happens the RM will produce a tarball, md5sums, and sign
>the release (ascii armor). This tarball will then be distributed to
>individual developers. Who will verify the authenticity of the tarball
>(using md5sums, the RM's signature via the web of trust) and test the
>build on whatever platforms they can.
>
>When they are +1 on doing the release with that tarball they create an
>ascii armor signature and send it to the RM. The RM appends that
>signature ot their own signature.
>
>When we reach a certain number of signatures (I was thinking 3 or 4) the
>person who has the project key signs the tarball with that and appends
>that signature to the signature file.
>
>Right now only the CollabNet guys can post files, so it makes sense for
>them to have the project key. They can simply do the signature when
>they upload the files to the download server.
>
>The logic here is that it will be far more difficult to forge 4 or 5
>signatures than just one, project key or individual developer. As time
>goes along we can hopefully get everyones keys built up to the point
>that people using the web of trust to verify keys can verify all of the
>signatures.
>
>However, people who don't wish to go to the trouble of connecting to the
>web of trust can simply verify our key once. And continue to use that
>verified key from release to release to check the authenticity of the
>tarball.
>
>
Since I mess around with security stuff might I tender a little
possibility? One thing that could increase trust in the keys would be to
utilize a hardware security token. I use one (Dallas Semiconductor Java
iButton) with an x.509 security token but this token has the capability
to support additional applets (in the JavaCard sense, not the J2EE
sense) that can use a generic security API with generalized hardware RSA
acceleration. In fact, I think there is someone out there that has
written an applet for it that can do gpg signatures. I know someone has
written an applet to support ssh key operationns. At any rate the
thought here is that this token security stores the private key so that
it is impossible (well, to a degree... power analysis and other stuff
like that has defeated some devices but not this one that I know of) for
someone to get a hold of that key. They'd have to steal the physical
device and sniff your PIN from somewhere. It would take a bit of code to
get this working but if you want to take the security to the next step...
--
Jens B. Jorgensen
jens.jorgensen@tallan.com
"With a focused commitment to our clients and our people, we deliver value through customized technology solutions"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 20 05:37:32 2004