The frustrating point that keeps coming up is this. Although "fixing
the gateways" is the right thing to do, it is simply unacceptable to not
have secure email until all the gateways are fixed.
I'm afraid this is basically counterproductive. The reality is that there's no
path that gets us usable secure email without getting gateway support in place
first. So, while getting such support in place first may be unacceptable to
you, it really is the only way that secure email is going to happen. So the
choice becomes very simple: Do you want secure email or not? If you do, you
need to face up to the fact that the gateway problem is real and you cannot
work around it. Instead we have to solve it, and unfortunately then we have to
wait for implementations to catch up. This is frustrating, I agree, but I see
no other viable course that will work.
It isn't like we haven't tried to solve the problem without getting gateway
support in place. In fact we've been frantically trying to do things this way
for well over five years now. And after huge implementation efforts, tons of
discussion, lots of standards writing, and all sorts of furious ancillary
activity, where are we? Nowhere, that's where. We're still butting our heads up
against the same set of problems we had five years ago. And worse, had we
actually faced the problem head on five years ago and written a specification
for what gateways should do with MIME objects this problem would have been
solved by now since the initial implementation MIME in literally hundreds of
gateway products would have taken these issues into account.
In fact it would be fair to say that nothing we do now will ever be able to
recoup the the loss of the first and best window to get this sort of support
into gateways. We blew it, plain and simple. (I count myself as part of the
failure to get this done properly since I should have fought harder to keep the
language about gateways in multipart/signed, not to mention MIME and ESMTP.)
Now, you may argue that since we've missed the chance to do this right we might
as well give up and continue to try various half-assed ways to work around this
problem. But there's no evidence that such approaches will in fact work any
better in the future than they have worked thus far. And furthermore, there is
considerable evidence to suggest that new language in Internet specifications
will in fact cause gateway vendors to mend their ways. In fact there is
evidence to suggest that this will not only happen, it will happen rapidly.
So I suggest that rather than waste another five years with the same end
result we instead try to tackle the real problem.
Therefore, we have
a need for two formats, hopefully evolving to one in the future.
I do know one way to have a single format which serves both needs. It's
called content duplication (i.e. multipart/signed and signedData in a
single message) and was the basis for the original S/MIME proposal 2
years ago. It's awfully unpopular and has a lot of wierd potential side
effects but it seems to work.
Your own words argue explain why this is a nonstarter -- you say it was awfully
unpopular. And with all due respect, this is being kind. The use of this format
generated a firestorm of protest and probably has delayed S/MIME by at least a
year if not more. And not only is there no reason to believe that it will be
any more successful now than it was before, there is considerable reason to
believe that it will be _less_ successful.
Here's why. The previous attempt to use multipart/alternative in this way
happened at a very unfortunate time -- it was a time when a bunch of products
appeared that also generated extra MIME parts in messages in various
proprietary formats. Microsoft Exchange and the infamous MS-TNEF parts is the
most widely known example of this, but there are a bunch of others. So there
was a flood of messages containg material end users saw as useless crap.
It doesn't matter that this stuff is useful under some circumstances, the
point is that users didn't see it as useful. And while S/MIME's use
of multipart/alternative was small beer compared to the sins of others
like Microsoft, its coincidental presence caused it to be tarred with the
same brush.
And all this in turn forced a bunch of gateway vendors, myself included, to
implement something we had resisted implementing for many years -- we added
capabilities to summarily delete attachments from messages. We simply had no
choice but to do this -- the market pressure was overwhelming. And these
capabilities are now widely deployed and system managers understand how to use
them.
So now when a product starts emitting messages with, say, a PKCS wrapper around
signedData, it won't take system managers more than a few seconds to add this
to the (long) list of "crap to delete". After all, it isn't like it damages
messages any to lose this part. All it does is preclude the deployment of
secure email products on either side of the gateway later. In fact I predict
that deployment of part removal will proceed in advance of deployment of
secure email, making secure email practically impossible to deploy across
gateways.
Don't get me wrong, message bloat is a
_really bad thing_. Maybe the time is right to revisit if it is a
_worse_ thing than having two signature formats...
The real problem with this format isn't message bloat or the security issues it
raises (which continues to make it a showstopper for me, BTW), it is the added
message complexity. A few lines of additional junk at the beginning of a
message are one thing, a vast sea of binary gunk at the end that looks like a
useful attachment but isn't is quite another. Users will not tolerate it and,
due to the previous use of this format and what it did to gateways, system
managers will be ready and able to take care of their user's demands in short
order now.
So what's it to be? Are we going to learn from our mistakes and solve the real
problem? Or are we going to not pay attention to our own dismal track
record and waste even more time?
Ned