Subject: web page on Web of Trust

From: "Carl Ellison" <[email-masked]>
Date: 2 Sep 2000 19:21:37 -0700

After getting too many people confusing SPKI/SDSI's non-CA certificate
issuance with PGP's Web of Trust, I wrote the following web page.

http://world.std.com/~cme/html/web.html

Feedback is, of course, welcome.

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison         [email-masked]     http://world.std.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

---

From: [email-masked]
Date: Sun, 3 Sep 2000 13:23:45 -0700

> http://world.std.com/~cme/html/web.html

This page doesn't really define "web of trust".  It says,

"...PGP incorporates a security fault tolerance feature called the Web
of Trust.  Under the Web of Trust, multiple different keyholders sign
each certificate (each binding between UserID and key), attesting to
the validity of that binding.  The assumption is that these different
keyholders are independent so that even if one of them makes a bad
judgment, they won't all do so.  It is also assumed that no false binding
will have more than the specified web of trust number of signatures."

This is focussing on the idea of using multiple partially trusted
introducers in order to build confidence in a binding between key and
name.  However I think the defining characteristic of the web of trust
goes beyond this aspect.

If we look at the name, what we have first of all is a web.  This is
a network of interconnected elements.  Mathematically, it is a graph.
But the name "web" implies a certain kind of random structure to the
graph.  It is not hierarchical, it is point-to-point.  End users connect
to other end users within the web.

Secondly, the web connections indicate "trust".  Here I think the term is
a misnomer within the PGP context where it was created, because actually
the connections in the PGP case don't show trust, they show validity of
key-name bindings.  (The new meta-introducer signatures do show trust,
but they came later.)  Broadly, we can say that there is an element of
trust because we have to trust other people if we are going to rely on
their certifications of key-name bindings.  We could also say that we are
asking whether we can trust a given key to be useful for a given purpose,
such as encrypting email to a particular addresss.

So a web of trust is a decentralized, non-hierarchical, cross-connected
network useful in making decisions relating to trust, and in our case
specifically to cryptographic trust in the sense above.

(BTW epinions.com, an online product review service, has also adopted
the term "web of trust" to refer to an eBay-like reputation system.
http://www.epinions.com/help/index.html?show=web_of_trust.)

This definition does seem to include SPKI.  Even though the question
being answered by SPKI is not the same as that for PGP, the mechanism has
many similarities.  Users utilize their keys to issue certificates which
point at other keys.  The set of all certificates, considered as pointers
in this way, forms a web much as in the case of PGP.  And the question,
in the end, is whether a given key is useful for a given purpose, can
it be trusted to be used for that purpose.  So the web is used to make
trust decisions.

As I understand it (which may not be 100% correct), SPKI is even more
of a web of trust than traditional PGP, because it allows for explicit
delegation of certification power (similar to the PGP meta-introducers).
When you issue a cert with the delegation bit set, you are trusting the
receiver to delegate that power appropriately.  Furthermore, this trust
propagates through the web as his delegatees may make delegations of
their own.

In my opinion, any decentralized trust management system, whether
PGP, SPKI, or the various research trust models like AT&T's KeyNote
and PolicyMaker, can all be considered to implement a web of trust.
The important element is the lack of a centralized hierarchy which is
imposed on the trust decisions.  (Of course webs of trust can usually
support hierarchical trust models as a special case.)

The biggest difference between SPKI and PGP is that SPKI is primarily
oriented towards authorization certificates (is this cert holder
allowed to use this resource?) while PGP is oriented towards identity
and authentication certificates (who is this cert holder?).  I'm not
sure how the SDSI aspect fits into SPKI; the way you have described it,
SDSI names sound so completely idiosyncratic as to be almost useless,
and I'm not sure what question they answer.

Hal

---

From: [email-masked]
Date: Sun, 3 Sep 2000 13:49:20 -0700

As a further follow-up, here is a long message I wrote for another
mailing list a year ago proposing a way to think of the relation between
identity certification systems like PGP, and authority certification
systems like SPKI:

The problem with key-centric approaches is that it is not clear that
a key has behavioral attributes.  In some cases it does, as when there
is an automated server which uses its key in specified and limited ways
under the control of some automated program.  But in many or most cases,
keys are wielded by humans; they are the slaves of humans, and the keys
have no say in how they are used.  It is humans, ultimately, who bear
the responsibility for what the keys do, and it is humans which should
be involved in trust-related decisions.

I see it like this.  End-use attributes can be put directly on keys in
many cases.  A given key is authorized to unlock a door, or to request
a web page.  But once you start trying to delegate authority, it is best
to start using names.  Then there needs to be a specific subset of the
PKI whose only job is to associate names with keys.  This subset is what
PGP tries to address.

Given this subset as a base, you can freely interchange key-centric
and name-centric certificates.  You can give authorization to use some
resource by name, or by key.  You can give meta-authorization to delegate
the use of some resource, and in this case it is probably best to do it by
name.  I believe, contrary to the SPKI philosophy, that most authorization
and credential decisions are best handled by name rather than by key.
That is human nature, that is what we are familiar with.  You can't
punish a key, you can't argue with it or complain when it does something
inappropriate.  We have evolved social systems which allow for cooperation
and trust, and we need to retain the essential attributes if we want to
move these interactions into the electronic realm.

In this view, the problem PGP tries to solve, which is to bind names
to keys, is logically distinct and separate from the problem of an
attribute based certification structure like SPKI.  PGP provides an
identity certification structure.  It doesn't try to do more than that.
You could then add a new and separate cert structure designed to handle
other kinds of attributes.  The identities can now be used as building
blocks in this new cert structure; you can think of the new structure as
either name-centric or key-centric, because both are now equivalent.

It is especially attractive to see the identity PKI as existing solely
to facilitate the use of the attribute PKI.  Its only job, in this
perspective, is to provide the name-key bindings that allow the attribute
PKI to use names and keys interchangeably.  In practice, this is not quite
right, because the name-key binding that PGP provides does have utility
in its own right, namely in helping users determine that messages were
signed by certain people, or in finding keys to allow them to securely
encrypt messages to their friends.  But if we ignore these uses then we
have the identity PKI solving a problem which is not very interesting
(name-key binding) but one which adds convenience and intuitive depth
to the attribute PKI.

It is true that in setting up the identity PKI, you do have some
structural similarities to the attribute PKI.  If John is trusted to issue
identity certificates, maybe he is also trusted to issue good-credit-risk
certifications.  These tasks look rather similar.  But I argue that this
is misleading; from the perspective above, the identity certification
is useless in itself, and is only there to be one of the paving stones
on which the attribute certification, which is the interesting one,
is built.  John's role in issuing identity certs is a rather sterile
and formal one, merely binding names to keys, saying who owns what keys.
Statements like these don't in themselves have any operational influence
on the real world.

It is when he and others start making substantive statements about the
keys and their holders, statements about what they can and cannot do,
or what they are like, or what their proclivities are, that we have some
meat on our PKI and we can start doing useful stuff with it, like ecommerce
and delegation of authority and granting various powers and privileges.
Names are just labels, and the identity PKI is there solely to give us
the ability to use names when we are ready to do real work with the
attribute PKI.

In short I see the task of the identity PKI as fundamentally different
from the attribute PKI.

Hal