Hi,
At the risk of prolonging this thread...
I asked Ben Laurie a few days ago to respond, given his background
and because I had the feeling he would have a pre-baked answer to
the shared key issue. His response, forwarded with permission.
Sander
Forwarded Message from Ben Laurie:
> From: Ben Reser <ben@reser.org>
> To: dev@subversion.tigris.org
> On Thu, Apr 08, 2004 at 02:55:59PM -0500, kfogel@collab.net wrote:
>
>>Okay. My feeling, after reading the whole thread, is that we should
>>
>> a) Forget about the shared key for now.
>>
>> b) Make sure that three or four developers sign each release.
>>
>> c) Make an effort to get all developer's keys into well-connected
>> trust networks (pretty easy, considering that we have a high
>> degree of personal contact/overlap with other projects like
>> Debian, Apache, etc).
>>
>>I hope Ben Reser will forgive me for (a), considering that I was in
>>favor of a shared key before... Two things changed my mind:
>>
>> 1. It would have made the CollabNet developers "special" when it
>> comes to releases. (Although this specialness wasn't a
>> necessary property of the system, it would have been the path of
>> least resistance for a while.)
>>
>> 2. It complexifies the whole system generally. Everyone's got
>> their own ways to manage their personal keys. But with a shared
>> key, we have to coordinate how to manage it.
>>
>> 3. While we *think* the shared key would be easier for users, do we
>> actually know this? IOW, premature optimization.
>>
>>So, how do people feel about this simplified version of Ben Reser's
>>proposal?
>
>
> I have to disagree 100%. The arguments so far against it IMHO have been
> repeated talking points of "It's bad".
>
> Here are the problems I see with the arguments against it:
>
> 1) Since the people presenting these arguments are comfortable with
> GPG/PGP and the web of trust. They assume other users will be. I think
> the whole web of trust thing is fundamentally confusing to end users in
> general. If you don't believe me go look for all the FAQs about it.
> It's not easy to explain, understand or use.
I agree with this, and will reiterate my response: KeyMan.
> 2) They assume there is no shared trust. But is is flat out wrong.
> When I download and use Apache, I'm not trusting the individual
> devleopers. I'm trusting the ASF and the various contributors. It's
> based upon the belief that there are checks and balances and that while
> I can't necessarily trust an individual developer that I don't know, I
> can trust the group due to their track record and the process they have
> in place.
>
> Trying to express that shared trust with only individual developers keys
> is IMHO a serious mistake.
>
> Since we all reasonably "know" each other it's much easier to see things
> as trusting individuals. But our users don't know individuals. They
> know a project name.
If we agree that users don't understand WoT, I don't see why a shared
key named after a project is any better for an end user than some random
developer's key?
> 3) They claim that shared keys are bad. And they're right in an ideal
> perfect world. But in an ideal perfect world a lot of security models
> that are just downright unusable in the real world can exist.
>
> Fact is we deal with shared keys every single day. The biggest and most
> widely deployed instance of this is the entire SSL/TLS infrastructure.
> Certificates are signed by shared keys, e.g. the certifying authorities
> key. There is no individual name attached to that key. It's not even
> attached to a specific domain name. We actually have to trust out of
> faith that it truly belongs to the certifying authority and that they
> are taking their best efforts to only use it apropriatly and securely.
Indeed we do - and we should use our best efforts to ensure that
signatures on code distributions are secure. Using shared keys does not
achieve that aim.
> 4) Doing a shared key and individual signatures doesn't disallow people
> who don't trust or like shared keys from authenticating with only
> individual keys. Not doing the shared key just increases the work
> required for a user to use this authentication method. Meaning users
> who don't have a path to any of the developers who signed the release
> will end up falling back on the md5sum.
The problem is, as you have said, users don't understand the issues. If
we provide them with a weak key, they will use it and trust it. That is
irresponsible.
> Additionally, individual keys mean a user might have a trust path for
> one release and not another one depending upon who signs the releases.
This is why developers should sign each other's keys.
> 6) It doesn't complicate things. It only complicates things if the
> people who dislike shared keys try to push their views onto the shared
> key.
It only complicates things if you have any concern for its security. If
you don't care about security and just want to sign releases because it
looks good, then a shared key is certainly the way to go.
> I think the requirements they try to put on the shared key really aren't
> necessary. We can do them if we really want to be that paranoid, but I
> think they're unnecessary. Frankly, I'd let the people who can upload
> releases have access to this key. Provided it was given to them in
> person.
The problem is much less giving it to them (in person or otherwise) - it
is taking it away from them.
> Again nobody is forced to use this shared key. It's an option to the
> end users.
Which you don't believe are capable of making an informed decision.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 13 22:45:31 2004