Derek,
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.
Correct me if I am wrong, but the point is that anyone can deposit a key, and
there is no checking for duplicates or any enforcement of the identity binding.
Out of curisoity, what is the lookup mechanism for a user's name -- what
corresponds to the DN?
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.
You could, in which case you would be a public archive provider in my view,
regardless of the directory or file structure you chose to use. And using
Kerberos to provide some additional level of authentication is not a bad idea
at all, if you already have the necessary Kerberos infrastructure installed.
Doesn't work too well across organizational boundaries, of course, because
Kerberos itself doesn't work very well across those boundaries. and it doesn't
provide as neatly wrapped and sealed a certificate as does X.509, despite
having to go to as much or more work to accomplish the same ends.
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!
Yes, and vice versa, by intent. I didn't mean to imply that the direct trust
model didn't have any validity, especially in the Persona type of situation
where anonymity is desired (assuming that you use a trusted blind-forwarding
service to disseminate your mail.
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!
True enough. You could also be your own CA, and self-sign your own certificate.
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?
Yes, to a certain extent it does. But I can set up contractual relationships
with my own CA, and between my CA and my PCA that will provide me some degree
of protection against these kinds of attacks. And if I am a reasonably cautious
user, I don't put very much confidence in Joe Pond Scum's CA, any more than I
would in Joe himself. that's why I said that the user has to be able to control
his root keys, and either decide for himself on a message by message basis, or
set up some filters as to whose CAs will be believed, questioned, or rejected
out of hand.
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!
I agree, and I feel that PEM has sufficent mechanisms to accomodate this,
namely the Persona certificate. At least in this case, unlike the general PGP
case, it is obvious when someone is using a pseudonym.
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?
Assuming that no authority or other types of permissions have been granted,
perhaps by an extended X.509 certificate, we could argue that it SHOULDN'T mean
anything else. Unfortunately, some folks claimed that was going too far, and
would remove any potential utility for such certificates for business purposes.
Others who were more knowledgable in the law than I am claimed that without
some explicit disclaimer, the implicit attribution of agency would still be
there. I have suggested putting such a caveat into the X.509 certificate
directly, if necessary using the Description field, and in addition putting a
strong notice to that effect in the PCA's policy statement.
Unfortunately, the confusion as to what an X.509 DN "ought" to look like led
people to reject such a contrived DN, and the original version did not provide
any other place in which to put such information except in the DN (an oversight
that is now being fixed.) I have so far not ben able to persuade the major PCA
players, notably the RSA Commercial Hierarchy, of the wisdom of including such
a caveat.
Bob
--------------------------------
Robert R. Jueneman
Mgr., Secure Systems
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820 (rolls over to cellular and/or my house
if no answer -- have patience)