So what you're proposing is a way to "cheat" MIME.
The alternative, application/mime, also "cheats" MIME. The
application/signed proposal attempts to limit the scope of the
"cheating" to where it is absolutely needed, in opaque digital
The correct term isn't "cheat", I'm afraid, it is "violate". The current
application/mime proposal is in clear violation of the MIME specification. The
MIME specification EXPRESSLY FORBIDS the use of encodings other than 7bit,
8bit, or binary on composite types. Since application/mime is clearly
composite, this is in violation of one of the more strongly worded clauses in
all of MIME.
I have a major problem with this, as you might expect. My problem stems from
the fact that when we designed MIME we were basically providing a sort of
guarantee as to what sorts of objects implementors would be presented with. And
one of the things we clearly intended to guarantee was that binary MIME would
not be hidden inside of other MIME objects, so implementors who elected to use
a line-oriented strategy to parse MIME would be safe.
This is in fact a logical extension of the care we went to not to break
implementations written in good faith to conform to RFC 821 and RFC 822 that
could only handle 7bit. We decided then that we could not make such a
non-backwards-compatible change to the infrastructure, and we based this
decision on the fact that previous attempts to develop multimedia mail
solutions hadn't made comparable guarantees and had failed as a result.
This current proposal basically does the same thing we decided against six
years ago, this time to extant MIME parsers. We have already heard from one
major vendor, Netscape, that their implementation won't handle this. And while
they may in fact be forced to change their implementation to support binary
MIME under encryption (an entirely separate issue, since an encrypted object
isn't purely composite), they should not be forced to change because we're
retroactively changing what MIME says is legal at this late date.
Finally, as a practical matter, this working group to-be doesn't have the
authority to change MIME in this way in its charter (in fact a co-director of
the applications area has said that it is unlikely to be chartered at all) and
I doubt if a charter opening up MIME in this way would be approved in any case.
The history of this is rather unfortunate: when both MIME and PEM were
both under development, their respective WG meetings were scheduled at
the same time. Thus the MIME specification, complete with its "no
recursive encodings" rule, was designed without the input or feedback
from the security community. When it later came time to do digital
signatures in MIME, this rule seriously got in the way.
Frankly, I doubt that the PEM WG would have been able to change this even if
they had tried. While it is true that I have always thought that the recursive
encoding prohibition in MIME was excessive and that it would have been better
to simply prohibit the use of binary encodings at the leaf level on any
transport that doesn't support binary, I was a lone voice in favor of this
approach. The overwhelming majority of WG participants were in favor of banning
recursive encodings entirely.
In any case, application/mime, application/signed, and
application/pkcs7-mime all have the issue that they are capable of
transporting binary MIME objects over traditional e-mail transports. If
this is desirable, it needs to be explicitly called out in all the
specs. If it is not desirable, it needs to be prohibited. We currently
have non-interoperation of application/pkcs7-mime due to this very
I think application/mime and application/signed that allow binary encoding
inside are a nonstarter. I for one will certainly object to such a
specification getting registered, let alone being placed on the standards
track, and I suspect I will not be alone. I would not mind application/mime and
application/signed that allow for recursive encoding of all but binary leaf
objects, but I doubt if my personal preferences matter much here -- the
obstacles that have to be overcome here would be huge. Frankly, I think that
this group is doomed to destruction if it pursues this course -- asking the
IESG to charter a group after failing to meet the stated criteria the IESG said
the group had to meet is one thing -- the IETF is nothing if not flexible --
but then asking to grant that group the authority to pry open one of the most
important application-level standards and change it in ways that will almost
certainly reset it to proposed status boggles my mind.