[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MLM and Web of Trust
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 7 May 1996, Hal wrote:
> I have a few thoughts relating to the "web of trust" versus
> hierarchical key certificate systems. This description is pretty
> elementary and is intended more for people who have not been familiar
> with the issues before. First some background.
[Excellent background deleted]
[Trust is not transitive.]
> The [trust is not transitive] situation reminds me of a maxim of
> multi-level marketing (MLM) companies like Amway. These businesses
> typically sell a product, but they use a pyramid scheme for distribution
> where people not only sell the product, but try to recruit others to
> sell for them.
[...]
> To achieve success, though, the saying goes like this: You not only
> have to sell; you not only have to teach your people to sell; but you
> have to teach your people to teach people to sell.
[...]
> The analogy to transitivity of trust is this. If you want to have
> transitive trust, you have to be sure the other person knows how to
> securely sign keys. But you also have to make sure he knows how to
> make sure that the next person knows how to securely sign keys. And
> further you have to make sure he knows how to make sure the next guy
> knows how to make sure, and so on.
[PGP avoids transitive trust because of this problem and others]
Ok, so if the problem is with transitive trust and not the technical issue
of security of signatures, why not a hybrid of the vertical and web
models?
PGP's primary problem in my view is that signatures are not flexible
enough, or they are too flexible. A signauture can mean anything. When I
sign a document signed by Bob, does that mean that I am vouching for Bob
as the author of this document, or that I agree with the document, or that
I certify that the document (regardless of my belief in its points) merely
passed by my desk on this date?
Similarly, when I sign a key. Am I of the opinion that the "real name"
associated with this person is the only person in possession of the key,
of the opinion that this person is indeed (insert real name here) or am I
siging off on the e-mail address?
It seems to me that two things need to happen to improve the web of trust.
First, signatures have to be application specific. Sure you can put the
words "This signature means that I believe XYZPDQ etc." at the bottom of
that which you are signing, but this method both lacks any kind of
standardization and further requires some sophisticated logical thinking
and a lot of planing by the average user.
I'd much rather see signature applications integrated in the software in a
simple way.
PGP currently asks:
READ CAREFULLY: Based on your own direct first-hand knowledge, are
you absolutely certain that you are prepared to solemnly certify that
the above public key actually belongs to the user specified by the
above user ID (y/N)?
Why should PGP not also ask:
READ CAREFULLY: Based on your own direct first-hand knowledge, are
you absolutely certain that you are prepared to solemnly certify that
the above document is accurate in all respects (y/N)?
or
READ CAREFULLY: Based on your own direct first-hand knowledge, are
you absolutely certain that you are prepared to solemnly certify that
the above user is a careful and competent individual with the skill and
means to secure his secret key (y/N)?
or
READ CAREFULLY: Based on your own direct first-hand knowledge, are
you absolutely certain that you are prepared to solemnly certify documents
signed by the above key are from the internet address associated with it
(y/N)?
or
READ CAREFULLY: Based on your own direct first-hand knowledge, are
you absolutely certain that you are prepared to solemnly certify that
the above financial transaction corresponds to your exact wishes (y/N)?
or
READ CAREFULLY: Based on your own direct first-hand knowledge, are
you absolutely certain that you are prepared to solemnly certify that
the above user is not only a trusted introducer, but is fit in your
estimation to gague the security and signing skills of other users and
vouch for their fitness as trusted introducers (y/N)?
It seems to me that integrating these issues, having a developer think
them out ahead of time for the user would be a valuable thing. This
solves, to some degree, Mr Finney's "AOL" problem. (Wherein he expresses
concern over the differing skills of internet users and the ways these
difference complicate the web of trust).
Part of having an effective web of trust is defining exactly what a
certification means. I don't think the web of trust fails because it is
non-vertical, but because it fails to define what certificates mean. It
_imposes_ (or at least suggests) horizontal decision or treatment of a
certificate when it may be prudent for novice or moderately skilled users
to treat them vertically. Yet to simply switch to a vertical scheme will
frustrate expert users who wish to maintain the flexibility of a
horizontal one for whatever reason. (They don't trust institutions,
prefer to have more stringent or otherwise non-standard certification
policies, etc.)
Using certification that allows either (but perhaps defaults to vertical)
can easily be envisaged.
Software could be configued to trust only a institutional certifier to
designate trusted introducers as a default, (Perhaps an online security
mutiple test would be a good way for such an institution to make the
determination?) and yet users who wanted other schemes could select the
more expert options and designate their own introducers and introducer
introducers.
READ CAREFULLY: Do you trust the above user to (enter all that apply):
A) Introduce other keys for the purposes of secure communications and
document certification with those keys?
B) Vouch for the security consciousness of other users?
C) Vouch for the fitness of other users to certify introducers for your
web of trust?
D) Vouch for the financial fitness of other users?
(etc.)
Really it's no more than an extension of the "trust bit" that is already
in PGP signatures to other areas.
In addition I think it's important to extend this kind of flexibility to
all manner of signing activites.
I revoked a key some time ago because it was getting old and because 2048
bit keys were made available. That revocation certificate could mean
anything. It could mean I KNOW it was compromised, it could mean I
suspected it was, it could mean I found my secring.pgp file on a multiuser
system where I did not myself put it, it could mean I left a disk with my
secring.pgp on it in a library, or it could mean the key expired.
How are you to know unless I write up a complicated statement and sign it
and take pains to publish it all over creation?
Why doesn't PGP simply ask:
Are you:
A) Certain this key is compromised?
B) Of the view that it is probably compromised?
C) Worried it might be compromised?
D) Revoking this key because it is expired?
E) Issuing a general/non-specific revocation?
Again, standardized, easy for the user to understand, easy to distribute,
and very clarifying.
Someone could easily write a module which defined and updated these
differing trust issues for PGP and users could pick the codes they
prefered. (A trust model flash rom?)
fincer - Certification with respect to financial integrity
ident1 - Certification with respect to true name identity
ident2 - Certification with respect to accuracy of e-mail account
secrt2 - Certification with respect to the users ability to keep a secret.
etc.
Don't force clever and sophisticated users to bow to a vertical system
when they don't have/want to.
> Hal Finney
- ---
My preferred and soon to be permanent e-mail address:[email protected]
"In fact, had Bancroft not existed, potestas scientiae in usu est
Franklin might have had to invent him." in nihilum nil posse reverti
00B9289C28DC0E55 E16D5378B81E1C96 - Finger for Current Key Information
Opp. Counsel: For all your expert testimony needs: [email protected]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMY/SZmqgui0rHO4JAQFkfwP/XqGH79Z0HX0fF8FvtrxAZB5JbnaMi3K4
gwt1zlQD8ni3n8+6fD887u6vyqxwty8AuQ4BwdxfPfFNecfgcZ8BHv8F1aMopV1x
4clVrHknaKo1BR83MEiEpN74yFebj0fsTlLxijLDbUA5z33Spmcn5Eek21nv4yXR
W1ZWUd5uSIk=
=vpLU
-----END PGP SIGNATURE-----