Bottom line. The old mechanism blew it. We can sit and pontificate for
hours and get nowhere discussing this issue.
Previous versions of TIS/PEM allowed users to create arbitrary
distinguished names (contrary to the specs) and allowed users to create
arbitrary hierarchies (also contrary to the specs). It all still lost.
The market was not interested. Period.
Jim, I am also respectful of your position, and the amount of effort that you
have put into this. And as you say, we don't have to agree.
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.
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'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. 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.
i
I would therefore prefer that we begin the process of updating
both the existing PEM spec and the PEM/MIME spec to take
advantgae of the v3 certificate format, which would make what
you are trying to do even easier and add a lot of other
capabilities as well. But what you are trying to do can also be
done with the version 1 format, so I would vote NO on any effort
to standardize on the key selector approach as it presently
exists.
I still fail to see the problem with the key selector. The serial
number of a certificate is a key selector. All we've done is generalize
the concept since we don't necessarily have certificates.
And that is my fundamental objection. Maybe we shold call it PGP/MIME?
Bob
--------------------------------
Robert R. Jueneman
Staff Scientist
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820