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.
Again, it depends on what you mean by compatible. You cannot turn a
PGP signature into a PEM signature or vice versa, but you can sign something
with both. Presently you cannot send the same encrypted object to both
PEM and PGP recipients.
You can, however, use the same basic set of hooks into the messaging system
to attach both of them, and you can reuse quite a bit of low-level code.
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.
You have to be more specific about what implementations you're referring to.
You certainly don't need separate mail systems or separate mail software.
You may or may not need separate security packages integrated into the mail
software.
The days when the most complex part of the mail software was the security
subsystem are long gone. It is no longer possible to talk about adding
a production-quality mail system to a security package as an afterthought.
Even interfacing the two takes quite a bit of work without MIME there to
help you.
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. :-)
I'm afraid that they *are* insurmountable for small to medium sized companies
and personal users.
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.
Well, my problem here is that you what you propose doesn't agree with this.
You're asking people to learn to ride without any sort of training wheels.
Even self-signed certs raise the bar too high. I would also argue that there's
a distinct advantage to having something of a transition between the
non-cert and cert-based approaches. Not much of one, mind you -- you should
not need to switch from PGP to PEM for example. But something that indicates
that you're getting something different now.
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.
Couldn't have said it better myself. This is exactly what classic PEM offers
now.
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.
As I said before, I have not tried RIPEM because it offered no way to
transition to the REAL service until recently.
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.
But now you've bought everyone into setting up their distinguished names and
all that. I don't think this is a viable place to start when your entire goal
is to add a little security. In fact it is barely viable when setting up X.500
services, where your entire *intent* is this one capability. And setting up
X.500 services is something I happen to know a lot about since I sell and
support X.500 software.
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!
AND THE EXACT SAME THING IS TRUE OF THE PRESENT MIME/PEM SCHEME.
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.
I think you are hoist on your own petard here. By using identical mechansisms
for what you see as different levels or qualities of service you are blurring
the distinction between the two to the casual user. MIME/PEM uses
non-identical mechanism for non-identical levels or qualities of service, and
I think this has MAJOR advantages over sleazing around with certs the way
you (and apparently RIPEM) want to do.
Ned