My assessment of the "failure" of PEM is different than yours, perhaps because
of a different perspective of the market.
We picked up the TIS/PEM reference implementation and documentation, and
despite the efforts of four experienced computer science professionals, we
couldn't get it to work sufficiently well that we could be persuaded to go
forward with a greater effort. It runs on a Unix platform, when probably 90%
of
our users use Macs or PCs. It included an integrated mail handler, which we
didn't want, didn't need, and couldn't support. And it had an ugly interface
that was cumbersome to use, in addition to some real questions about
implementation from the standpoint of security. In short, it wasn't ready, not
even nearly ready, for the corporate world. It was also even more unsuited for
the residential user who didn't have a staff of computer science majors to
debug it and make it work for him. But little if any of this had anything to
do
with the certificate structure.
My experiences with TIS/PEM were entirely different. I took the code and ported
it to a non-UNIX environment. A lot of effort was required, mostly because of
the way TIS/PEM managed keys (the LKM process and all that stuff). But
eventually I got it working. There were bugs, of course, and the management
interface was ugly, and the security model really wasn't appropriate to our
environment, and so on, but this simply wasn't relevant to me, since I planned
to replace all that stuff with my own code.
I stalled out, however, on two other fronts. The first one was my effort to
actually use TIS/PEM to do things. There was no PCA I could tie into. (Jim and
I tried various things at one time or another with the TIS PCA but it never
came together.) The CRL support never worked, first because of code problems
and then later because I didn't have and couldn't get the necessary CRLs. What
with one thing and another I finally had to give up -- it just wasn't going to
happen. Moreover, I didn't (and don't) see the software as being the real issue
here -- the problem is that things need to work first, then you build
infrastructure with them, not the other way around.
Second, I tried to tie TIS/PEM into our MIME-based mail system. After a fairly
impressive battle in this area I found that the resulting code was necessarily
very complex and nasty and using it was not intuitive at all. I eventually got
the viewer working, more or less, but the signer/encrypter parts just plain
wore me out with their compatibility and complexity problems.
And then came the latest TIS/PEM. The key management has been completely
reworked around key selectors and is now sane and reasonable. The support for
integrating the services is done in a way that makes it basically a drop-in for
most MIME software. What a change!
I had someone else do the port, someone who had never seen the code before, and
it only took them a week (it took me about a month the first time). The
management interface is now clean and sweet, and much of the simplification in
this area is a result of the new key selector scheme. And once it was done we
could sign and verify and encrypt and decrypt. It all works! I cannot tell you
how pleasant this was compared with the suffering I endured with classic PEM.
For my part I handled the MIME support end, and it only took me two days to get
the basic infrastructure in place and working. Our big discussion now centers
around whether we want to let users sign and/or encrypt parts of messages, or
force them to always sign and/or encrypt the whole thing. It is easy to be
flexible, but the problem is that people may not understand what signing just
some subpart of a message implies in terms of security.
It is a very refreshing change to have gotten this far with any PEM
implementation with so little effort.
You say that you already supported using "nonstandard" distinguished names and
"nonstandard" hierarchies, and the market ignored them. Doesn't that give you
a
clue that that wasn't the problem?
I can't speak for anyone else, but I ignored them for two reasons:
(1) Much of the trouble was caused by certificates. This didn't get rid of
the need to have certificates.
(2) They were nonstandard, and I wanted to do thing the "standard" way.
I'm respectful of your position Bob. We don't have to agree. I would
like to point out though that we are not abandoning certificates. On
the contrary, we 100% support them, both in the specifications and in
our implementation. We'd prefer people use them but recognize that the
current community of users of encrypted electronic mail don't. There
must be a reason.
I don't mean to dismiss the PGP users out of hand. But on the other hand, I
don't see any great wave of PGP encrypted or signed messages flowing over the
net, either.
You aren't paying much attention then. I see more and more of them in my daily
mail all the time, both in personal correspondence as well as on lists. I
finally had to get PGP and install it because I wanted to correspond with some
other people about sensitive matters and PGP was the only way I could do it.
And I do't see anyone in corporate America, in the EDI or
Electronic Commerce area, in the electronic benefits and tax filing areas, or
in the federal, state or local governmental level adopting PGP to any
significant degree. That leaves the academics, the AOL newbies, and a few
stalwarts such as Rhys who are having to build a system from scratch because
of our obscene export control requirements.
Don't kid yourself -- significant corporate activities are being conducted
under PGP security already, and that usage is set to increase as no other
viable solutions present themselves.
The lack of a comprehensive trust model is much less of an issue than you might
think. For one thing, given the extensive sorts of bilateral agreements that
always have to be in place before communication can occur, the necessary
agreements to exchange the necessary PGP materials are trivial. (EDI only makes
this worse in that you also have to agree as to the format of the messages
you're going to send. But in practice EDI has its own security facilities
anyway, so neither PEM nor PGP are necessary very relevant in the EDI
community.)
May I remind you that PGP dealt with the MIME integration issue over a year
ago? (And here we are, two years later and counting, and we haven't done
squat.) True, the way PGP did it is now seen to be an error, and there's a move
on to use the security multipart mechanisms we're discussing with PGP, but the
old way does work and people do use it.
Ned