In other words, they use different certification code, text processing
code, key and certificate representation code, etc. One would have
to parallel all the RIPEM code with PGP code anyway, so I don't know
why you wouldn't just use PGP if you want PGP. I appreciate that you
are trying to build bridges to bring people in, so let me ask, what
advantage would you see with putting PGP compatibility in RIPEM? It
is already the case that PGP compatibility at this level is not
planned for PEM, which RIPEM follows. I expect the PGP community to
propose their own MIME formats - that's why the PGP identifier was
removed from this draft of MIME/PEM.
Once again this ignores the very real advantages of using a common MIME
framework for both services. It may be true that you want to use separate
security code for PEM and PGP (I question the general truth of this given the
fairly significant overlaps in the necessary infrastructures), but you don't
want to use separate MIME processing facilities for either one, nor is there
any need to have separate facilities.
I wasn't suggesting that you implement PGP compatibility. I was just thinking
aloud, and wondering whether such an approach would be feasible, and/or
whether
you were considering some kind of compatibility feature.
It most certainly is quite feasible. RIPEM is of course free to follow whatever
course it chooses -- just because it is feasible doesn't mean RIPEM should do
anything differently. But just because RIPEM doesn't do something doesn't mean
that other courses of action are infeasible.
My crystal ball fell on the floor and broke a while ago, so I don't know
whether PEM, RIPEM, PEM/MIME, PGP, or encrypted mental telephathy will
eventually become the dominant means of providing privacy and/or integrity for
data communications. I hate to see the user community divided and unable to
communicate and interoperate, but even more I hate to see the scarce resources
that are available stretched to support two or more different public-key
infrastructures.
There's a big difference between interoperating in the sense of having
compatible security services and interoperating in the sense of having a
framework with slots where more than one service can easily be added. I see the
former as being a nonstarter for all sorts of reasons. The latter, on the other
hand, is exactly what the security multiparts give us (assuming, of course,
that there's ever some closure on this list).
I'm concerned that if the PGP community goes off and implements a PGP/MIME,
not
only will they not be able to interoperate with PEM or PEM/MIME, they might
not
even be able to interoperate at the MIME level, and so my MIME-reader might
not
be able to read their equivalent of MIC-CLEAR.
They will assuredly interoperate at the MIME level as long as the security
multiparts mechanism is used for both. And you most certainly will be able to
read their equivalent of MIC-CLEAR if security multiparts are used for both.
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.
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.
3. Co-opt them by including compatibility mechanisms.
This is practically impossible to do in general.
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.
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.
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.
Ned