Jeff,
In my opinion, the things that are slowing deployment are:
1) Lack of aggressively marketed commercial implementations (where people pay
real money, get at least minimal support, and someone is motivated to "sell"
it).
This affects the mass market more than this community.
Actually, according to Jim Bidzos, the use of Apple's AOCE is taking off rather
nicely. People are using it for internal forms, though, instead of e-mail. This
is probvably due to (1) the fact that they don't have a good e-mail package
that would support deigital signatures and encryption, and (2) companies
would like to test the water with internal uses fo digital signatures before
they
swim out into the ocean with inter-company signed messages. The differences
between the AOCE certificate infrastructure and the PEM infrastructure are
comparatively minor. This helps the overall infrastructure effort, but not PEM
per se.
2) The tie to X.500 names. With 20/20 hindsight, I think this was a big
mistake.
We thought we could take advantage of a certificate infrastructure
that someone else would have already paid for and installed; then we thought
we could be leaders and people would be willing to put up with some pain
because
the certificates would be useful for other things. While dreams persist that
the certificates deployed by PEM will be useful in other contexts, those dreams
are now sufficiently distant that I don't think anyone will deploy them unless
they are justified solely by the utility of PEM. The price we pay is that to
deploy PEM, you need an X.500 name, and while that might not in theory be
difficult, it is at least a source of confusion and a psychological hurdle.
Actually, I am beginning to believe that we will never see PEM deployed until
we see other applications developed. The infrastructure cost seems to be too
high
to be justifiable for just e-mail privacy, and digitally signed e-mail may be
perceived as
presenting more problems than solutions.
If we had life to live over, I would advocate using internet mailbox names
(or things that look like internet mailbox names) as the basis for
authentication instead of X.500 names. Clearly, many members of this
community disagree with me (probably a majority). And even I believe that
it's too late to switch (at least in an abrupt manner). Some people clearly
think we should (probably a minority).
I believe that the issue is more the requirement for, and implications of, name
subordination, and therequirement to get corporate approval to set up a CA.
Conceivably many of the same issues would have arisen if the Internet mail
address
were used instead. Certainly there would be problems of using e-mail names with
DOCKMASTER, CompuServe, American Online, etc., accounts, unless personal rather
that corporate sponsorship was intended.
3) The practical difficulties in getting linked into the CA hierarchy.
This is caused in part by the "top-down centric" view in the design
coupled with our appalling inability to actually deploy an ICA and a
casual-use-appropriate PCA.
I agree that this seems to be the primary problem, and strongly linked to #2.
While I
don't agree with Rhys Weatherley entirely (apologies to both Rhys and Anish
Bhimani
for misspelling their names), I think he makes some very good points in this
respect.
I don't think that self-signed certificates are the answer, because they may
give you a false snse of security. However, I am beginning to believe that
a low-assurance, automatic responder that would issue certificates to users
based on their e-mail address may have some merit to jump start this process.
I don't view the lack of an IPRA/ICA as a significant barrier, for he available
implementations wouldn't support the IPRA key in any case. But is there a
serious problem with a casual-use PCA? I would think that both the TIS PCA
and the RSA Persona would fill that role.
4) Continuing uncertainty over integration with MIME.
I can't help that much. I'd like to see that happen, but can live without it.
What is much more important, in my judgment, is the absence of _any_ Windows
or Mac implementation that can be used in a corporate environment without
running afoul of licensing issues. I'd be happy to pay for even a poor
implementation,
just to get started.
5) Psychological barriers caused by the mystique of cryptography, export
controls, and lawyers; coupled with perfectionism inherent in the desire
to get the certificate infrastructure right the first time for fear we
won't get another chance.
I think there is something to that as well.
The reason I proposed changing the certificate format was to try to address
some of the
problems that seem to be inherent in the X.509 Distinguished Name, but maybe
this
is too tough a problem.
What if we took a "damn the torpedoes" attitude toward politically correct
DNs, and just coded them up anyway we can get them to work. E.g.,
C=Cyberspace, CN=" Robert Jueneman <jueneman(_at_)GTE(_dot_)COM>"
No name subordination, no organization, no country, state or locality. Just the
equivalent
of a Residential Person, but without the residence. Do you think this would
help?