The current proposal deals well with this problem by making integrity
checked message intentionally not readable by a non-PEM aware gateways
or MIME readers. But by doing this, it throws out the more important
goal of MIME/PEM <=> MIME interworking! If I send an Integrity checked
message to you, if you do not have a PEM aware implementation, you
can't read it!!
I'm pretty sure this is close to universally false. I challenge you to find a
single MIME UA implementation where adding support for message/pem-clear is
going to be hard. In most cases it is a two-line change to a configuration
file.
My own implementation is likely to be about the hardest one to change (I
actually have to change some code since our understanding of MIME structure is
in coded in a subroutine library) but I figure it will take about 30 minutes to
implement this.
In my opinion, the place where implementations are going to have trouble is in
dealing with binary MIME. I believe that most MIME implementations were written
in a binary-aware way (the standard certainly goes out of its way to deal with
binary issues and hence recommend this approach), but I seriously doubt that
this capability has received much testing. MIME-PEM will certainly test it, one
way or another.
If we in fact weight the ability for a Non-PEM reader to read integrity
checked mail over the ability to work transparently across deployed
gateways, (I do!!) then the following proposal may make more sense.
Proposal:
Require that the data portion of a multi-part PEM always be encoded
into a 7 bit form. As a 7 bit object it should not need to be
transformed by most intermediate gateways.
I don't have a huge problem with this... I just don't think it is going to
interoperate as cleanly as you think.
Advantages:
The content-type of an Integrity checked message is available to a
non-PEM aware MIME reader. (Big win!)
I disagree. The win is small; making UA implementations handle
message/pem-clear is easy in most cases.
Disadvantages
Gateways between MIME and X.400 will need to be PEM aware to do the
right thing.
The problem isn't limited to X.400; gateways to ANY environment that supports
multipart messages will have this problem. This includes Novell MHS, cc:Mail,
MicroSoft Mail, Banyan Vines mail, Message Router, and many others.
Another disadvantage is that this proposal also violates the letter of the MIME
specification. Specifically, if you privacy-enhance a multipart object that
requires encoding, the result is that the top-level object gets encoded, which
isn't legal for a multipart.
There is no prohibition for against a MTA to muck with the encodings
for any reason (i.e., upconvert to 8 bit) so there is a possibility
the encoding may be changed even when not necessary.
Exactly right -- I don't know how many cases we're going to have of gateways
delving into the guts of the first part of a multipart/pem object even when
they don't need to, but I can pretty much guarantee that it won't be zero.
I doubt any of the current MIME gateways suffer from these
disadvantages yet, and future ones can be designed (profiled?) to be
PEM aware.
Dream on! I don't have to look very far for a counterexample: we've been
shipping gateway products for X.400, cc:Mail, Novell MHS, and Message Router
for well over a year now. (We started shipping right after closure was reached
on the MIME standard but before RFC1341 came out.) I know of at least one other
commercial gateway implementation that's already deployed besides ours.
And in case people think that the issues surrounding upgrading user agents
versus gateways are comparable -- well, they aren't. The primary difference is
that user agent issues are an end to end thing; if you're running a MIME UA and
you get PEM stuff that doesn't view right you can usually edit one
configuration file and be done with it. Gateway problems are completely
different: all it takes is one intermediate gateway between originator and
recipient to screw things up royally and neither the originator nor the
recipient will be able to fix it.
Ned