Carl,
PEM makes use of certificates to provide sereval security
services. The sender of a PEM message would like to be able to
unabmigously identify each recipient. While unambiguous
identification could be provided in a variety of ways, PEM uses the
DNs bound into X.509 certificates to achieve this in a fashion which
should be able to scale to encompass a very large (worldwide) system
of users. It should be possible for a PEM user to send (encrypyed)
mail to someone with whom he has never communicated via email, and
thus for whom the sender does not have knowledge of the recipient's
mailbox name, etc.
Being able to determine the mailbox address for a user with
whom you have nevert exchanged email is a goal of directory services
such as X.500. Our intent with PEM is to extend this capability to
the secure email domain. (Note that the names used in PEM for
authentication are not used for routing decisions; these names are in
addition to, not in lieu of, the exitsing DNS mailbox names.) Thus, we
want identifiers for users which can be matched to various real world
user attributes. This makes it likely that the identifier securely
bound to the user's public key can be independently evaluated by a
prospective sender as being the identifier for the "right" user.
Also, we don not want to have to trust widely available databases
(directories) to maintain bindings between keys and names, hence the
use of certificates, signed key-name binding data structures.
From a recipient's perspective, receipt of a signed message is
not very useful if the identity of the sender cannot be established.
It is technically feasible to send signed email to ANY recipient
without ANY prior arrangement on the part of the recipient. In this
situation, it is especially useful if the recipient can verify the
signature and be able to determine the (unambiguous) identity of the
sender simply by examining the sender's (cryptographically verified)
identity, and relating this identiti to the sort of realworld
attributes alluded to earlier.
PEM originally dictated a high assurnace binding of DNs to
keys, but there was considerable sentiment that this level of
assurnace was not uniformly practical and that there were also
personal privacy reasons for accommodating other forms of identity
binding. Thus the current PEM certification scheme incorporates a
layer of policy CAs to allow for varying levels of confidence in the
name-key binding in a fashion which allows the user to make an
informed value judgement about the binding.
None of this disputes your observation that there are other
ways to provide identifier-key bindings. However, schemes which do
not ensure global uniqueness of identifiers, do not seem likely to
scale well, or may make it easy for users to be confused by duplicate
names are unsuitable. Schemes which do not provide a well defined
means of allowing all users to make informed judgements about the
quality of the name-key binding are likely to result in confusion for
users and maybe some very nasty surprizes. Schemes which rely on
users carefully examining a sequence of certificates to establish a
sense of trust in the name-key binding seem unsuited to scaling and to
a user population which has trouble programming VCRs. Thus PEM has
adopted the X.500 model for naming and certification and imposed some
constraints on that (very general) model to explicitly accommodate
diverse certification policies.
Steve