Steve Kent on certification trust paths

[gnu]

Steve is one of the key folks in the Internet PEM project.  He sent this
message last month during a discussion of why PEM uses top-down
key certification rather than the "mesh" style that PGP uses.

I hope that our (cypherpunks) experience with mesh key exchange will
teach us a lot about whether and how it works.  Nobody has ever tried
this before, so we are doing research!

	John Gilmore

------- Forwarded Message

Message-Id: <9210212125.AA27956@TIS.COM>
To: Peter Williams <P.Williams@cs.ucl.ac.uk>
Cc: pem-dev@TIS.COM
Subject: Re:   Perhaps OSI security is not possible in a liberal community!
Date: Wed, 21 Oct 92 17:24:42 -0400
From: Steve Kent <kent@BBN.COM>

Peter,

	You have receibved replies from a couple of folks (via
pem-dev) who have expressed views on why a strictly hierarchic
certification system is not required.  As the author of the words you
cited in raising your question, and as an advocate of a strict
certification hierarchy, let me respond.

	It is clear that one can construct a certification system
which is not a tree, but rather is a mesh.  The PGP approach is an
example of such a scheme and X.509 permits this.  However, there are a
number of advantages to a hierarchy which have motivated its use in
the Internet:

	In a pure certification mesh, one acquires certification paths
by following chins of implied trust.  It is not at all obvious that
this approach scales well.  The PGP folks do not yet have significant
experience in this regard, so it will be interesting to see how the
mesh develops over time.  Most folks who have spent considerable time
exploring this issue believe that unbounded transitive certification,
with no required name relationships, is a bad idea.  The rationale is
that whatever trust one might accord to an entity may not apply
transitively.  I may give a house key to my neighbor to be able to
open my house under certain circumstances, but that does not suggest
that I would give the key to whomever that neighbor provides his key.
It seems difficult to characterize the nature of trust in these
"lateral" arrangements and applying trust transitively is even more
difficult.

	From a user interface standpoint, it is generally agreed that
most users are not capable of evaluating a certification path.  In PEM
we feel that a user should know the distinguished name (or an alias
assigned by the user locally) of a message originator/recipient, and
some indication of the policy under which the user was certified,
e.g., a short-hand name for the PCA.  This is about all we expect a
user to be able to deal with.  The though of a user really paying
attention to (much less applying meaningful value judgements to) all
of the DNs in a certification path boggles the mind.

	I won't clain to understand all the details of what PGP
provides for managing key rings.  However, if one were to provide a
management tool for mesh certification in general, I think it ought to
permit a user to construct a trust graph expressing the relationships
implied by certification paths he acquires.  The user might be able to
express a degree of trust and a level of allowed transitive
certification for each entity in the graph.  Disply of this info, to
allow a user to manage the graph, would be necessary.  All in all, it
seems to be pretty complex and it is highly questionable if most
(many?) users could make use of this facility without getting
confused.  But, this analysis is based on reasoned speculation, not
actual experience.

	The naming issues is a related, but somewhat indepedent topic.
DNs provide many good features for use with a certification system.
One wants the names to be globally unique and manageable in a
distributed fashion.  Being able to express a through, rich name is
important if this technology is ever to expand beyond casual use in
R&D environments.  Note that DNS names are not great choices.
Although there are close to a million DNS host names, that represents
a very small portion of the population that one wants to serve with a
system like PEM.  Most DNS names are very short and will eventually
reuslt in collisions as more individual and organizations are
registered.  The problem is worst in the U.S. where we have adopted a
parochial scheme with GOV, EDU, COM, ORG, and MIL at the top, vs.
other countries which prefix their DNS names with a country code.
What's worse is that many DNS indivdiual names are not very mnemonic
and thus don't offer much in the way of indentification outside of a
very narrow context.

	There is sometimes confusion about the role of certificates.
X.509 makes it clear that they serve only for identification, not
authorization.  This is improtant because it is difficult enough to
manage them for identification purposes without overloading
authorization info on them.  Also, the entities who grant
authorization may often be different from those who vouch for the
identity of an individual (or organization) and thus this independent
is appropriate.  Often there seems to be a desire to bind more info
into a certificate in support of authorization, but I (and many
others) believe this to be a mistake.  One can construct other
certificates (like the PACs EMCA has defined) to use public key
technology for authorization, leveraging off of certificates used for
identification.


	Finally, there is revocation.  We have adopted both a push and
a pull facility for CRLs in PEM and the PEM CRL format differs
slightly from that in X.509.  Many folks fail to appreciate the
subtleties of CRLs at first.  Hot listing on a CRL says that either a
key has been compromised OR a name has changed.  If we have
fine-grained, organizationally-related names, then these names will
change with some frequency and thus CRL entries will arise.  Because a
certificate establishes a binding between a name and a key, it seems
appropriate that only the entity which vouches for this binding (a CA
of some tyep) should be able to revoke it.  That is the model we use
in PEM and we add the important feature of having each CA advertise
when it will issue its next CRL, so that user's know when each CRL
they hold is obsolete.

	
	Peter, I hope this note helps explain the very terse words I
put in the PEM key management document.

Steve

------- End of Forwarded Message