Peter,
If you have not done so to date, I recommend the past several years of archives
of the
pem-dev discussion to you. As someone who has contributed probably too many
megabytes to the discussion of this and similar topics, I'll offer an opinion
of my own:
As in many other endeavors which involve standards and the contribution of many
individuals,
the initial PEM design and its further refinements represented a set of
compromises on
many individual points. Initially, I wanted to include many of the more
elaborate schemes for
delimiting the degree of trust that was to be represented by a certificate,
including text which
would specifically limit an individual's liability, etc. I had in mind
applications of this general
certificate-based encryption and digital signatures which would go
substantially beyond
conventional e-mail and would embrace contracts and other financial matters.
However, other
probably wiser heads persuaded me that we should probably build a trusted
e-mail system
first, then extend the model to cover other uses later. If I had known that it
would take so long
for PEM to be released I might have fought harder!
On the other hand, my experience in building an RSA certificate-based system
about
five years prior to PEM convinced me that it would be very difficult to
anticipate or legislate
just how individuals would want to build their trust model. In that system
(called STAMP,
built while I was at CSC), we implemented a local cache of Trusted
Correspondent's certificates
that was managed by the individual user himself. The user could put anyone's
certificate into
the Trusted Correspondent's cache that he wanted to, and he confirmed that
approval by
signing that user's certificate himself. In essence, the user became that
correspondent's
local certification authority.
Instead of an impersonal Certification Authorities, Notaries, etc., our system
used individuals
to sponsor or vouch for other individuals in a Chain of Authorization, but that
chain was quite
arbitrary in its construction. If a signed message were received from someone
who was not
already in that user's Trusted Correspondent cache, then the user had to decide
for himself
whether to honor the message, based on the chain of certificates obtained from
the user
(either e-mailed or sent via floppy disk). Obviously the user had to obtain and
approve a
Correspondent's certificate in order to obtain his public key before sending
him an encrypted
message.
In our implementation, certificates included a 255 character ASCII field that
described the
user's position, responsibility, authority, etc., in free-form English. The
user could include
whatever caveats and limitations he wished to within that field, including
referencing a
separate document called an Affidavit of Legal Mark which spelled out in
legalese the
circumstances under which the user's signature was to be considered binding.
In order to confirm the authenticity of the certificates in the chain it was
necessary to climb the
chain until the originator and the user had a trusted Certification
Authority/sponsor in common
(but not necessarily the Top of Chain of either of them). However, since
anyone in the chain
could have created a public/private key pair and then signed that certificate,
anyone
in the chain could conceivably impersonate anyone lower down in the chain. It
was therefore
recognized that the more links there were in the chain between the two users,
the greater was
the degree of risk. However, this risk is diminished if you have independent
confirmation from
the correspondent that he and he alone possesses the private key that
corresponds to his
certificate.
Although X.500 and X.509 provides a potentially useful scheme for looking up a
user's
certificate and other attributes, it is not necessarily the only way that can
be done and it has
some other drawbacks. For example, despite having been designed to accomodate
telephone
numbers, it has no provision for any kind of unlisted or unpublished number. I
continue to
believe that we may have sacrificed some useful PEM features on the altar of
standards
compliance, when those standards had not yet stood the test of time and
practical
implementation, but this is just a personal opinion.
In any case, regardless of what repository is used to hold the certificate, and
regardless of
what process is used to identify the user and bind the certificate to that
user, it is worth
stressing repeatedly that a certificate does not confer authorization for any
particular function,
and that in most cases even the basic identification must be considered
somewhat suspect.
Although the naming function may be hierarchical, it need not be, and even if
it is, it does not
follow that decisions about who is trusted, and for what, must flow
hierarchically. Peer to peer
relationships are probably more important in any real networks, even in
hierarchical institutions
such as the military.
KNOW YOUR CORRESPONDENT is still the best rule.