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.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 17 19:47:24 2004