Rob,
You bring up a lot of interesting points in your descriptions, but I
would like to correct some errors and comment on some of your
conlusions.
However, what the direct trust model does not do directly, and one of
its most serious weaknesses, is that it doesn't prevent me from
publishing a public key and claiming to be you. In this regard a PGP
key is like a business card. I
This is true. You can generate a key using any ID you wish. Whether
this is good or bad depends on your viewpoint. And actually, in PEM
you can generate a key with any id on it as well, but you need to get
it certified before it is of any use.
IF we had some kind of a readily accessible public archive of all PGP
keys and associated identities, then at least the innocent third party
would not risk having his reputation besmirched by someone claiming to
be him, assuming that the third party took the precaution of
periodically looking up his own name in the archive/directory to be
sure that someone hadn't deposited something there that didn't belong.
This exists today. They are called the PGP Public Keyservers, and
they are a repository for Public Keys. Anyone that wishes to deposit
their public key may do so in this forum, and anyone can look it up to
use or verify your key.
In this regard, a public archive provider (dare I call it an X.500
directory service provider?) could provide a useful function for PGP
users by acting as a surrogate form of certification authority and at
least examining the individual's claim to own a key, and by binding
the individual's identity with his public key in the directory. This
would be a rather weak form of binding that is not cryptographically
sealed, but it is at least a binding.
Why does it have to be a public archive provider in particular? Why
can't I be a CA for myself -- assuming people believe me. Why
couldn't I setup a CA for PGP keys here at MIT, and have people use,
say, the Kerberos installed-base of authentication to prove their
identity to the server.
The PEM model goes one step further, of course, and explicitly
introduces a third party, a certification authority, which
crytographically binds the individual's claimed identity with his
public key. Depending on the policy adopted by the user's Policy
Certification Authority, a variety of identification mechanisms could
be demanded by the CA in order to ensure that the individual is who he
says he is. this could range from no claim of identity at all
(Persona), to a self-certified claim, to a full-blown, pee in a
bottle,
So, you are saying that a Persona certification is as good as a PGP
certificate, eh? That's what it sounds like to me! And with PGP, I
don't have to go through all the headache of trying to get my key
certified -- I can just start using it as soon as it is created!
What's to stop me from creating a PEM certificate in the name:
"Robert R. Jueneman <Jueneman(_at_)gte(_dot_)com>"
You say I need to get it certified. Ok, I take it to a Personna CA.
Now I have it certified. Now what? Now the use has to make a choice
as to how much to trust that CA! Gee, this sounds very much like the
PGP model, doesn't it?
I'm not saying that the PEM model is worthless. Quite the contrary,
one of the best features of PEM is the rigourous hierarchy that is
being created. That is where PEM is good, and where it is useful:
That there exists a means to verify the real identity of a person, if
that person wishes to be identitied! That is the key! If I don't
want to be identified, I shouldn't have to be; and if someone else
doesn't trust me as a result, that is their choice. But it is still a
choice that the end user should make, and that is PEM's problem!
You're completely on the mark with regard to liabilities on CA's, but
that problem is not at all limited to PEM. The question is, what does
a CA's signature on a certificate (be in PEM or PGP or some other type
of certificate that hasn't been thought of, yet) mean, other than that
that CA vouches for the identity of the owner of the certificate in
some manner? The next question is, should it mean anything else?
-derek