RE: web of trust

["Noel J. Bergman" <no...@devtech.com>]

> Having the keys connected to each other is not useful. What is useful is
> having them connected to someone you trust.

> >   Suppose there is a downloader who wants to verify a /httpd/ package.
> >  Unless he/she allready trusts some key in the set, he/she has no
> >  clue how to /use/ the trust is the httpd key set.

> That's what Keyman is for :-)

Is this something that should be considered with respect to the Repository
effort?  We already have the idea that since the repository will be
mirrored, we have to include verification.

The repository needs to be neutral in terms of supporting distribution of
something like platform-specific code httpd as well as Java projects.  CPAN,
JNLP, dependency location and loading, RPM installing, etc., are concepts
layered on top of a basic repository construct.  But right above the basic
storage is verification, and if we had a specification and tools (a Java
version for portability), what would be the correct behavior in terms of
providing verification?

> What I said: "how hard is it for Joe Random to find a path from his key
> to the code signing key?" - though really I mean "from a key he trusts
> to the code signing key".

Here is where I see a problem.  Not with process, but with people.

Joe Random downloads software, doesn't understand signing, and just wants
someone to say that everything will be OK.  The average linux user may be
more clueful than the average Windows user (over 90% of which are largely
computer illiterate), but that's changing as linux becomes more consumer
friendly, and Mac OS X users are no more competent than their Windows
counterparts.  Perhaps this is why some people feel that MD5 is as good as
PGP.

As for finding a key that Joe Random trusts, whom would you suggest that Joe
trust?  Joe trusts whomever he's told to trust.  Joe trusts the Root CAs
that are installed in Joe's browser and mail program.  But Joe almost
certainly doesn't know any particular person to trust, and almost certainly
has no personal connection to a Web of Trust.  Yet, Joe is the person
downloading and using the software.

And although we know that "trust" only means that we have reason to trust
the IDENTITY of the signer, that's not what Joe Random will take from the
term.  Joe will take it to mean that the code is trustworthy, not the
identity of the code signer.

So what can we do for Joe Random?  It seems to me that what Joe wants is to
know that he has downloaded software that hasn't been corrupted.  I doubt
that he has any interest in the person who did the package, but rather the
entity whose name is associated with the package (the ASF).

I don't have an answer.  Just questions about what we can do for Joe Random.

	--- Noel

Re: web of trust

[Ben Laurie <be...@algroup.co.uk>]

Noel J. Bergman wrote:

>>Having the keys connected to each other is not useful. What is useful is
>>having them connected to someone you trust.
> 
> 
>>>  Suppose there is a downloader who wants to verify a /httpd/ package.
>>> Unless he/she allready trusts some key in the set, he/she has no
>>> clue how to /use/ the trust is the httpd key set.
> 
> 
>>That's what Keyman is for :-)
> 
> 
> Is this something that should be considered with respect to the Repository
> effort?  We already have the idea that since the repository will be
> mirrored, we have to include verification.
> 
> The repository needs to be neutral in terms of supporting distribution of
> something like platform-specific code httpd as well as Java projects.  CPAN,
> JNLP, dependency location and loading, RPM installing, etc., are concepts
> layered on top of a basic repository construct.  But right above the basic
> storage is verification, and if we had a specification and tools (a Java
> version for portability)

Haha, very funny.

> what would be the correct behavior in terms of
> providing verification?

Keyman is documented here: http://keyman.aldigital.co.uk/

There's also an implementation in Perl for, err, portability.

>>What I said: "how hard is it for Joe Random to find a path from his key
>>to the code signing key?" - though really I mean "from a key he trusts
>>to the code signing key".
> 
> 
> Here is where I see a problem.  Not with process, but with people.
> 
> Joe Random downloads software, doesn't understand signing, and just wants
> someone to say that everything will be OK.  The average linux user may be
> more clueful than the average Windows user (over 90% of which are largely
> computer illiterate), but that's changing as linux becomes more consumer
> friendly, and Mac OS X users are no more competent than their Windows
> counterparts.  Perhaps this is why some people feel that MD5 is as good as
> PGP.
> 
> As for finding a key that Joe Random trusts, whom would you suggest that Joe
> trust?  Joe trusts whomever he's told to trust.  Joe trusts the Root CAs
> that are installed in Joe's browser and mail program.  But Joe almost
> certainly doesn't know any particular person to trust, and almost certainly
> has no personal connection to a Web of Trust.  Yet, Joe is the person
> downloading and using the software.
> 
> And although we know that "trust" only means that we have reason to trust
> the IDENTITY of the signer, that's not what Joe Random will take from the
> term.  Joe will take it to mean that the code is trustworthy, not the
> identity of the code signer.
> 
> So what can we do for Joe Random?  It seems to me that what Joe wants is to
> know that he has downloaded software that hasn't been corrupted.  I doubt
> that he has any interest in the person who did the package, but rather the
> entity whose name is associated with the package (the ASF).

The Keyman documentation discusses these issues.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff