Peter's comments and your reply make me think that we are moving in the right
direction, finally. Let me offer some additional observations.
I believe that our problem all along was (and is) that there is a continuum of
services and trust models that the user community needs, rangeing from a very
simple privacy and implied integrity model between two people who know each
other well, all the way up to quasi-judicial records endorsed by Latin-style
civil notaries for the international sale of goods worth millions or even
billions of dollars.
At the risk of oversimplifying, the primary difference between these two
extremes is the type of guarantees that are provided, and the credentials
(i.e., amount of liability insurance) of the guarantor.
Although PGP admitedly serves many useful purposes, its primary mode of
operation involves the equivalent of self-signed certificates. In other words,
it is the alleged owner of the matching private key that is proclaiming the
binding between a given public key and the identity of the user, in the
so-called direct trust model. If you trust the individual, then you can
probably trust that his public key is valid, and belongs to him.
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
have a wallet full of business cards, including some from the FBI, Secret
Service, etc. I could therefore hand someone one of the legitimate business
cards (no forgery was involved) and claim that I was that person, and in many
cases get away with it.
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.
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.
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,
fingerprint, retinal scan, and DNA sample taken type of identification
procedure suitable for intelligence agencies and other highly sensitive
functions.
Although this is a considerable step up the ladder (depending on your
viewpoint), there are still two serious problems with the basic PEM model.
First, the IPRA does not have any enforcment mechanisms, and some of the PCA
hierarchies that the IPRA has certified are sovereign governments. Short of
declaring war and winning, there is no way to compel such organizations to
follow any particular set of procedures, even their own. Basically, users who
are recipients of a document and want to know whether they can believe the
identiy of the individual who sent it must decide whether to trust the PCA who
is at the top of that individual's certificate hierarchy. The IPRA can provide
a level of syntactical assurance that the certificate chain appears to be
intact, but it cannot provide any semantic assurance. As has been pointed out
before, the user needs to have a mechanism to control what level of automatic
acceptance, warning messages and/or rejection is associated with individual
users, CAs, and/or PCAs, by controlling what "root" keys are stored in the
user's cache.
The second and perhaps more serious problem with PEM (and the first and second
versions of X.509) is that they only deal with identity, and not with
credibility, authority, or creditworthiness. The digital signature of a
pathological liar is still of questionable utility, and the fact that I
digitally sign a payment order doesn't necessarily mean that there issufficient
money in the bank to cover it.
The banking community (X9) has begun to address these problems, and stalwarts
like Frank Sudia and Warwick Ford have been doing God's work in trying to
codify a vast range of current commercial practices into extensions to the
basic X.509 certificate. I certainly hope that we can begin to progress toward
using the revised v3 certificate in the near future
In the meantime, in the absence of an explicit indication of authority,
liability, etc., there is at least a certain amount of implicit liability that
is associated with the use of a name, in particular a name that takes the form
of an organizational person. As a matter of fact, this implicit liability
doesn't even depend on the cryptographic certificate -- if I send an e-mail
message or a FAX to a firm ordering some peice of equipment and sign it with my
name and my company's address, my company will in all probability be liable for
my actions even though I was not authorized to place such an order, because in
doing so I gave theappearance of being authorized and the recipient firm had no
way of knowing otherwise. (There are obvious limits to this, and the higher the
dollar value of the transaction the more there is an obligation on the part of
the seller for due diligence as part of the sale.)
This problem becomes even more complex if the user's own company takes on the
role of certification authority and issues a certificate to that individual.
Without any caveats to the contrary, it becomes that much more likely that a
court would hold that an individual who siged a document using a certificate
which was endorsed by the company was acting as an agent of, for, and on behalf
of that company. And because company lawyers understandably want to limit such
exposure to those who have been specifically granted it, most corporations have
been noticeably reluctant to get into the certification authority business.
All of this may change substantially next year, when the US Post Office starts
issuing cryptographically signed identity certificates. Then, at least, it will
be pretty obvious that an individual is not an employee of the post office, and
that the post office undertakes no liability on behalf of that person other
than to provide a reasonable level of bureaucratic identity verification. I
certainly hope that this endeavor succeeds, and that it will put the basic
infrastructure in place that we have been seeking.
With regard to the question as to whether public keys have to be published or
not, my view is that they need not be published, so long as a reasonably
trustworthy third party has vouched for the binding between that public key and
the individual. Even ignoring issues of Persona support, there may be privacy
and other issues where I don't want to receive encrypted mail except from
certain people. In an X.500 directory, therefore, I would assume that the X.509
certificates should be subject to access controls, so that I can control who
can retrieve the information. Likewise, I may wish to control access to my
street address and phone number. However, if a PGP user can generate his own
public key and pretend to be me, then I would like to insist on publication,
just so I can have a chance to disavow that binding.
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)