John,
Sorry to have dropped out for a while, but let me see if I can jump
back in.
It's been my constant understanding of PEM that it has to stand alone
independent of X.500. There are two aspects of this independence.
First, we presume that X.500 directory services are not essential and
that PEM has to work without them. If X.500 directories actually come
into existence, so much the better, but since there's hardly any X.500
service in existence, PEM has to work with X.500 directories. This
means that we have to define and build effective means for
transmitting certificates to each other, retrieving them from
certificate servers, etc. Possible approaches inlcuding leveraging
off of finger, DNS, SNMP, FTP, building mail responders, or some
combination of these.
The other aspect of X.500 independence is in the specifications. The
notion of distinguished name and all of the rules governing DNs and
the certificate hierarchy have to be understandable without reference
to the "Directory." Terms like DIT, DSA, DUA, etc. are outside the
scope of PEM. This should have been easy, but I'm doscovering it's
not. Some of us have been laboring under the misunderstanding that
it's possible to define new attributes, e.g. E-mail name (EN), and
include them in the DN. However, it's become evident to me that it's
not possible to introduce a new attribute unless it's registered, a
"syntax" -- a peculiar name for what is really the set of legal values
for the attrbutes, i.e. the type -- is defined for it, and all
implementations are updated to know about it. This is an overwhelming
hurdle which effectively prohibits the introduction of new attributes
except very slowly.
Meanwhile, the introduction of PEM into the Internet is proceeding
very slowly. It prompts some reflection on the overall set of goals
and the corresponding design. In the interest of brevity, I'll skip
the arguments and simply highlight a possible direction:
- complete separation of the legal notion of identity from a network
identity based on e-mail names.
- separation of the certificate infrastructue from the ability to use
PEM, i.e. the ability to get going without a hierarchy and be
spliced in later.
- possible abandonment of both X.500 names and ASN.1 encoding.
- reconsideration of the role of CRLs.
- separation of signature and encryption algorithms
A design that might emerge from these simplifications is:
o I become "crocker(_at_)tis(_dot_)com", you are "jlowry(_at_)bbn(_dot_)com",
o we can each create keys and communicate with each other on our own
without approval from any hierarchy,
o we can also get our bindings certified by the hierarchy, and
o the hierarchy is aligned with the domain name system, so your
binding is signed by "bbn.com" and mine is signed by "tis.com."
(There are some technical details that complicate this picture, but
they're easy to work out or live with the blemishes.)
This system could be defined, implemented, and deployed quickly, and
it would be a lot easier to understand and use than the current
systems. Steve Kent has said multiple times that the problem with PEM
is that the current implementations are not as friendly as they could
be. That may be, but I believe there are also inherent difficulties
in the current design that will always be hard to overcome.
Steve