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.
Forwarded Message from Ben Laurie:
> From: Ben Reser <firstname.lastname@example.org>
> To: email@example.com
> On Thu, Apr 08, 2004 at 02:55:59PM -0500, firstname.lastname@example.org 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
> 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
> 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
> 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
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
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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Apr 13 22:45:31 2004