Re: web page on Web of Trust
hal@finney.org Sun, 03 September 2000 21:06 UTC
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12076 for <openpgp-archive@odin.ietf.org>; Sun, 3 Sep 2000 17:06:26 -0400 (EDT)
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA23616 for ietf-openpgp-bks; Sun, 3 Sep 2000 13:50:23 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23612 for <ietf-openpgp@imc.org>; Sun, 3 Sep 2000 13:50:22 -0700 (PDT)
From: hal@finney.org
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id NAA07806; Sun, 3 Sep 2000 13:49:20 -0700
Date: Sun, 03 Sep 2000 13:49:20 -0700
Message-Id: <200009032049.NAA07806@finney.org>
To: cme@acm.org, ietf-openpgp@imc.org
Subject: Re: web page on Web of Trust
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
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
- web page on Web of Trust Carl Ellison
- Re: web page on Web of Trust hal
- Re: web page on Web of Trust hal