Written by Ben Laurie:
> I agree with this, and will reiterate my response: KeyMan.
It'd be useful if he's "responding" off list to people on this issue
that we'd get the whole history of his responses. Not just this one
response. Or even better if he'd respond directly himself.
Based upon the URL John Peacock posted, I doubt very much that KeyMan
solves the problem.
You still have to figure out who's authorized to sign people into a
given domain. You suggest the ASF board would do this for Apache.
That's nice, now how do I know who the ASF board is?
And what if two project claim the same domain? Can anyone say Firefox?
Sure it avoids the key management issues with regard to a shared key.
But it doesn't resolve the real issue.
> 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?
Because a key that is used over and over gains trust simply by people
seeing it. You even mention that in your white paper. Individual
developer keys won't necessarily always be the same key. You can't gain
trust in them as easily because they're more likely to vary from release
to release. Plus, you have to figure out who's authorized to sign,
which is exactly the problem you're trying to solve with KeyMan.
I think a shared key is the only option to solve this problem for end
users that don't participate in the web of trust. KeyMan doesn't remove
the need to participate in the web of trust. It just makes it easier
for people using the web of trust to recognize individual signatures as
belonging to a certain project (though I have some doubts about it
really achieving this).
> 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.
A "shared key" is not necessarily insecure. It depends upon what you do
with it. It's just as possible to do insecure things with individual
keys as it is a shared key.
We can and should set policies on dealing with this shared key. E.G.
kept offline. Everyone should set a different passphrase on their copy
of the key. Passphrases should be secure and so on.
> 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.
I disagree that the key is necessarily weak. It's not as useful as a
web of trust where you know the developers. But then the web of trust
is better because of the connection to the person. There are some
people for whom it simply won't be possible to make that connection.
A shared key is a hell of a lot more useful than a md5sum. Would you
argue that we shouldn't provide md5sums because they're a weak method of
checking the release?
> > 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.
And this does not happen overnight. Especially when you have some
developers who aren't interested in signing keys without seeing
government issued ids. It might not even ever be possible to get a
complete web of trust between every developer.
> 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.
We wouldn't be having this discussion if we didn't care about security
and frankly I'm somewhat insulted by the insinuation you're making here.
> > 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.
I don't think I'm nearly as concerned about some contributor who leaves
the project (which I really think would be unlikely we'd give such a key
to someone likely to do this) doing a release they shouldn't as I am
some cracker who has no connection with the project. Even with code
review I'm sure a determined person could find a way to slip something
evil into the code.
Under an individual only key signing you still have the same issue.
Sure they don't have a shared key. But if this person has signed
releases for years, leaves, and then puts up a bad release, how many
people do you really think are going to be suspicious of the release?
This argument IMHO suggests that individual keys solve this problem. I
don't think it does. You can argue that your KeyMan project solves the
problem, but based upon what I've seen already I don't think it does
either.
> > 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.
I didn't say that. I said some didn't understand how to use the web of
trust. But that's funadentally different than understanding the
security issues related to it. One involves actually operating
software. The other involves understanding what the software is
attempting to do. Additionally, it takes some time investment to get
together with people to build a useful web. Someone people may not be
able to do that for whatever reason. Users are the only people that can
judge what their security comfort level is.
I equate your argument here with suggesting that GPG should only
generate the longest possible key length. Sure it might make it
prohibative for the end user to use for their application based upon
what they're doing or their hardware. But everyone should be able to
encrypt data in a way that could keep the US Government out of their
data... I find this to be a ridiculous idea.
Ultimately, it is up to users anyway. They may simply decide not to do
any verification too. We may think that this is foolish. But that's
not our decision. All we can do is provide the tools to do the
verification and educate them so they can make more informed decisions.
--
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 Tue Apr 13 04:15:12 2004