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