It certainly isn't clear to me what kind of a strategy to follow or suggest
at this point, even if we were all of one mind:
1. Ignore them, and hope that they go away.
This is what we're doing now, and it isn't working.
Agreed. In all probability, there is too much momentum, different cultural
assumptions, etc. The genie is out of the bottle.
2. Concentrate on building a better mousetrap, so the PGP users will beat a
path to our door.
Won't work. We need a different service with different characteristics.
It's clear that we need a different service from what PGP offers now. It isn't
quite so clear that they need something different from what were are trying to
offer, but see (1).
3. Co-opt them by including compatibility mechanisms.
This is practically impossible to do in general.
I though that you had previously argued the opposite. The MIME stuff can and
hopefully will be identical, and much, but not all of the digital signature
mechanisms can be reused. Different encryption algorithms and different hash
functioins may be involved, but they same may ultimately be true for DMS and/or
DSS-based systems. Just a different subroutine, at a high enough level of
abstraction.
The difference in the semantics of the trust models are the greatest barriers,
but if I _have_ to communicate with both kinds of users, I'd rather have one
implementation that does both, rather than having two incompatible
implementations to deal with.
4. Co-exist with them as equals, as 45 and 33 rpm records coexisted, or as
Beta and VHS coexisted, until one standard achieves market dominance.
I think this is a very useful parallel. We have the choice here of following
either the record or the videotape path. The record path is what security
multiparts and MIME/PEM do -- the various formats were brought into close
enough compatibility that the same machine could handle them all (as opposed to
Edison cylinders or disks), but they weren't the same and offered different
cost/benefit tradeoffs. The current situation is more like videotape, where you
either do one or the other, but doing both is hard.
Need I remind folks that in the case of records the LP won out eventually on
the basis of technical quality and merit? Whereas with Beta and VHS it was the
inferior technical solution that won. There's a lesson here for us.
Actually, in both cases it was decided on strictly the issue of capacity. 10"
LPs were produced for a while, but no one liked them. 12" 45's with a small hole
were also produced -- I have an awesome recording of Bolero on one. But Beta
couldn't record an entire football game or lengthy movie, regardless of its
superior resolution. The CD folks learned from that disaster, and set the length
of Beethoven's Ninth as the minimum capacity standard. I would argue that if PGP
does not provide the ability, at least ultimately, to provide a decent level of
nonrepudiation, it will eventually die out. I hope I'm right.
Let me ask you a more provocative question. The "conventional wisdom" seems
to
be that PEM has failed, and in fact failed miserably. Yet it seems that
perhaps
RIPEM has succeeded, if not brilliantly, then at least moderately. Is that
your
view, and if so, do you have any explanation?
Actually, my take on this is that RIPEM exemplifies PEM's almost total failure.
Up until fairly recently RIPEM wasn't PEM -- it didn't do all the required cert
stuff that is what makes PEM so incredibly problematic.
I have always steered clear of RIPEM in the past because of this -- if I'm
going to do PEM I wanted the whole thing as the standards said it should be.
But I couldn't get that through RIPEM or, as it turned out, through anything
else either.
And even now RIPEM finds it necessary to support self-signed certificates.
Excuse me, but this is nothing short of an admission that the infrastucture is
still problematic and must still be curcumvented to do real work.
As a pragmatic matter, I don't thnk that you will get any disagreement there.
The legal and organizations problems involved in setting up Certification
Authorties are considerably more difficult than we understood a couple of years
ago. They aren't insurmountable, as Motorola and Apple's initiatives have
demonstrated, but they require a degree of top-down involvement that requires
rare insight on top managment's part, or an absolutely brilliant presentation
from a bottom-up technologist. So far, I haven't been that brilliant. :-)
So we know that we have to permit some relatively simple tire-kicking at first,
then some bootstrapping, and then a wider deployment within a corporation will
come. But the issue is how much compatibility is there between the early
training-wheels systems and the later full-featured systems, how many systems
have to be scrapped, and whether and how you convert everyone in a company all
at once.
I'm not disagreeing with the need to support these simpler systems in order to
get started. But if I want to learn to fly at 30,000 feet, jumping out of a tree
may seem like a step in the right direction, but it won't get me to my goal and
I may break my neck trying.
That's why I have urged the adoption of a compatible, certificate-based system,
even if it uses self-signed certificates and doesn't have a viable CRL
distribution mechanism for these individuals. At least the databases, key
selectors, etc., etc., won't have to change to support a CA-based system. And as
Jeff has illustrated, you can even mix and match these systems.
Once we have a basic self-signed certificate capability, we can progress to an
automatic, e-mail based certificate generator that is a real CA, albeit with a
limited amount of trust in its PCA policy. Some of the braver, early-adopter
users might skip the self-signed certificate step and go directly to the
e-mailed certificate.
Finally, a large corporation can set up its own CA and operate it, and small to
medium users can go to the Post Office (or their bank, or their telephone
carrier, or Dominos Pizza, for all I care), and get them to generate a
certificate on their behalf as a trusted third party, with a higher level of
assurance as to the mechanisms employed and the standards of identity that are
required.
AND THE DEPLOYED CODE DOESN'T HAVE TO CHANGE AT ALL!
In effect the only real difference between the RIPEM approach and the MIME/PEM
approach insofar as the sematics everyone seems to worry so much about is that
the TIS approach is a bit simpler. If one compromises the service offering in
some way (I don't believe this but let's suppose) then so does the other.
I think the issue is one of compatibility and commonality of mechanisms. The
difference in trust between a bare key that isn't bound to an identity by anyone
other than the recipient, and that provided by a self-signed certificate, is
very slight -- perhaps non-existant. But in my view, at least, the compatible
self-signed certificate mechanism provides a smooth, easy growth path, with very
little that has to be relearned or thrown away, and no disruption in either the
originator or the recipient's way of communicating once the self-signed
certificate is replaced with a "real" one.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM