I should say that I'm not fundamentally opposed to application/{signed or
mime}, I just want to make sure we agree on the facts and the reason why we
need it.
That's similar to my position. We need to understand that we have
mutually incompatible requirements here. The usual method of obtaining
a specification through successive approximations made in response to
raised issues does not work well in this situation. To obtain a good
solution, people need to keep in mind the entire problem set and keep
straight which modes of operation address which requirements. This is
difficult to do in a typical list forum, where the group attention span
is rarely longer than two messages.
While I understand and appreciate all this red vs. blue stuff, I myself have a
much simpler view of the world -- I view it from the perspective of a gateway
to a non-822-non-MIME environment. And when you look at things from this point
of view you realize that there are two cases:
(1) The gateway talks to clients that have MIME-ware and signature verification
facilities available. In this case the correct thing for the gateway to
do is to tunnel signed objects without translation.
(2) The gateway talks to clients that don't have MIME-ware and signature
verification facilities available. In this case the correct thing for the
gateway to do is to treat multipart/signed or whatever composite object
is being used to hide the signed content apart (note that this includes
signedData).
Neither of these two is right and neither of these two is wrong -- sometimes
one applies and sometimes the other applies. And no matter what you do, no
matter what sort of tricky MIME composite types you define, no matter what
encodings you use, no matter what ASN.1 enclosures you use, the issue never
goes away.
This, of course, is a special case of a very general problem: The problem that
end-to-end security services are fundamentally incompatible with multiprotocol
networks. The minute you start talking about having two formats for application
data in a network while simultaneously supporting end-to-end security you have
to either tunnel one format inside of another (option (1)) or convert formats
and do whatever security you're able to do at something other than an endpoint
(option (2)). The issue is fundamental and can never be satisfactorily
reconciled. And BYW, if you think we're having problems, look at DMS sometime.
DMS is attached to X.400 at the hip. But the real world isn't all X.400, it is
a bunch of other stuff. So what you end up with is X.400 P2 floating around
inside of a security enclosure which in turn is inside of MIME. Anyone game to
tackle, say, the wide variety of BP15s, including but not limited to
FTBP, in a MIME environment?
So what do you end up with? The gateway has to be configurable and has to be
properly configured to do the right thing, and that's all there is to it. All
we're doing (and all we'll ever be able to do) is try and optimize behavior
based on what we think the defaults of most gateways are.
And this, in my opinion, is not the right way to develop standards. If we want
to mandate that gateways be able to choose (1) or (2), well then we should
simply mandate that and be done with it. And do not kid yourself -- the notion
of being incompliant with an Internet standard _does_ make a difference to
gateway vendors. We have proof of this in past actions, as a matter of fact --
the change in MIME to make the requirement that composite objects be supported
clearer worked wonders in the gatway world and got at least four gateways I
know of fixed.
This, to my mind, illustrates the real failure in the work we've done in the
IETF: We've fallen into exactly the same trap X.400 did and refused to deal
with gateway behavior. In fact we've done this over and over again. I
originally had language in MIME that talked about proper gateway behavior. It
was a long way from perfect, to be sure, but the feedback I got wasn't that it
needed to be corrected, it was that it clearly needed to be done away with. I
also had language in the ESMTP specifications that talked about gatewaying from
8bit to 7bit MIME -- it also was rejected and I had to remove it. I also had
language about the proper processing of signatures and decryption at
non-endpoints in the original security multiparts specification (actually,
Marshall Rose wrote it and I tweaked it -- this was before Jim and the other
TIS folks were even involved in the writing) and I had to remove it. And I
doubt if I'm the only one that has tried to deal with this area, and run into
this sort of resistance. And now, five years later, this shortsightedness has
come home to roost, causing us all to run around in tight little circles.
Fine, you say, but what about the issues that arise purely in the MIME world
with stuff switching around content types? Well, first of all, this really is a
gateway issue too -- specifically the one that should have been addressed in
the 8bitMIME ESMTP document. But even if it weren't, I think this problem has
been seriously overstated. In fact I am unaware of any current product that
gratuitously goes into all-7bit messages and changes the encodings or boundary
markers within multipart/signed. And even if there were such a product, I
seriously doubt that it is widely used. And even if it is, I think an argument
can be made that it doesn't comply with extant Internet standards, and as such
should be dealt with on the basis of its incompliance. (The same cannot be said
for gateways to LAN email systems since we've never bothered to address what
they should or should not do.) But no matter how you slice it the pure
SMTP/MIME gateway problem pales in comparison with the 10s of millions of users
that sit in front of non-MIME UAs that connect to the Internet via gateways.
There has also been a lot of talk about how the design of MIME didn't deal with
security issues correctly. With all due respect, I think this is hogwash.
Again, there are incompatible goals here that cannot ever be reconciled -- the
minute you develop a format for composite objects that has to coexist in a
world with many such formats you are at odds with end-to-end security. And we
had to have a composite format, so the only choice we could have made that
wouldn't have compromised future end-to-end security needs would have been to
abandon the development of MIME. For example, we could have allowed recursive
encodings in MIME and if anything it would have made matters worse, because
implementations would simply have pushed the encodings out to the leaves to
insure maxmimum legibility to non-MIME agents, and we would have ended up with
more message munging, not less. (And please don't tell me that they wouldn't
because I implemented my MIME parser when the specification still said that
recursive encoding was OK and this is exactly what it does.) Our only mistake
as far as I can tell is that we never specified what sorts of conversions could
be applied to MIME objects -- what a gateway does, in other words.
So where does this leave us? It leaves us with three choices:
(1) Continue to piddle around with MIME types in hopes of fixing something. I
think this is mostly harmless but also mostly useless.
(2) Switch to using signedData. I think this is actively harmful and also
doomed -- if it ever becomes widespread enough to matter gateways will
simply start decoding it and discarding the signature, and we'll be back
where we started.
(3) Try and fix the problem. This means writing some clear, crisp guidelines
for what it means to have a compliant gateway. This is hard, unpleasant
work -- make no mistake about it. And I'm sure it makes some people
uncomfortable since it means they have to depend on other vendors to solve
problem and not do anything themselves. The good feeling that comes from
doing something, even something pointless, is gone.
The option I think is best should be obvious.
Ned