In other words, the presence of this headers makes it trivial to
integrate PEM facilties into MIME UAs.
I agree that having a message/pem Content-Type would be highly
valuable. However it will not be trivial to provide it in a way that
preserves interoperability across gateways.
PEM itself is what introduces most of these interoperability problems. It has
nothing to do with the headers per se.
Gateways may perform a variety of transformations on plain text
messages, such as character code translation, whitespace
removal/padding, etc. When a message passes through a gateway, the
gateway can perform any necessary transformations on the encrypted
representation of a message, but not on the the underlying plain text
message.
This is precisely the of thing I'm trying to avoid. A gateway that performs
these sorts of transformations on the encrypted representation will in all
probability damage the encrypted material beyond any possibility of repair.
Accurate labelling prevents this from happening. True, it does not solve the
problem of not being able to perform the desired transformation on the
underlying plain text (which may actually be nothing of the sort). But it does
not hinder such transformations either; in fact, making it easier for gateways
to know when they have PEM on their hands opens to door to several possible
solutions that would not be possible otherwise.
The inability of gateways to manipulate the underlying plain text of a
message may result in the message being difficult or impossible to read
after being decrypted. A solution to this problem would be for
gateways to add a parameter to the Content-Type line to indicate the
transformation the gateway would have performed if the message had not
been encrypted. If the UA is then able to perform all of the
transformation that the gateway(s) were not able to perform, then the
message will be as readable as it would have been if it had been sent
as plain text.
This is an excellent idea and I'm glad you mentioned it. The issue of tracking
conversions and transformations performed by gateways is a very important one
and is one of the first items on the "to-do" list for the upcoming gateway
requirements document(s). Understanding the transformations that have occurred
is essential information in many cases, especially when something bogus is
happening.
Your point here basically is that transformations and conversions that were
requested but could not be performed are equally important. I must say I'd
never thought of it this way, but it sure makes a lot sense. And there could
definitely be all sorts of reasons for a failure -- the inability to remove a
PEM wrapper is just one of many possibilities.
While all this is really good stuff, I really don't want to get into it here
for a couple of reasons. First and foremost, the issues are such that they need
a general solution that's built on top of MIME. The gateway requirements work
is intended to produce just this solution. We don't need a different (and
probably incompatible) solution to this problem that's specifically for PEM.
And second, these are issues that are tangential and largely unrelated to the
problems I'm proposing we solve expeditiously. Look at it this way -- assume
you have a MIME and PEM aware gateway that's doing the translations and you
don't have the PEM-identification headers. How are the conversion problems this
causes any different than those caused by a MIME-aware gateway processing PEM
messages that have PEM-identification headers?
Ned