At the last PEM WG meeting (at the Boston IETF) the agreement
was that we would begin working on how to integrate PEM and MIME, but
we don't have a solid approach yet.
First, a historical note: The single biggest hindrance to resolving these
issues was scheduling. Practically without exception the PEM Working Group has
met at times that neatly overlapped the MIME Working Group meetings. As a
result is was very very hard to keep the efforts synchronized. I for one would
have been more than willing to attend the PEM meetings and start work on
integration well over a year ago. However, as coauthor of MIME this was a
practical impossibility for me to do.
I mention this simply as a matter of context -- I'm not blaming anyone nor am I
saying that it could or should have been handled better. It happened this way,
here we are, and that's that.
Next, some comments on MIME implementation work and adoption. MIME is catching
on quite rapidly. Practically every mail user agent in widespread use either
already supports MIME or work is underway to make it support MIME in a future
release. This is also true of many gateway packages. The existence of two
public domain software packages from the day MIME became a proposed standard
(to say nothing of the release of commercial software that followed shortly
thereafter) has made the adoption of MIME a lot more painless than it might
otherwise be. Even IBM, normally not a company you'd expect to endorse new
standards quickly, was demonstrating MIME-compatible user agent technology at
InterOp.
It is all happening a lot more quickly than I ever hoped it would. And this
places the PEM integration issue in a more difficult position than might apply
otherwise.
The present situation isn't pretty. PEM and MIME not only don't interoperate,
they can clash. Consider this scenario:
(1) A system generates a PEM message; its body is marked as containing
encrypted material.
(2) The message passes through a MIME-aware MTA. As a matter of course
it gets converted to MIME. But the MTA is not PEM-aware and therefore
the message looks like plain text. It therefore winds up as a plain text
bodypart.
(3) The message passes through a MIME gateway to some other type of mail
system. Since the body is plain text it may well undergo some sort of
transformation (translation to rich text format, for instance) that is
entirely inappropriate for encrypted contents.
(4) The message arrives at the PEM-capable destination, and is of course
unusable.
Or how about this one:
(1) A MIME message is generated inside some sort of secure enclave.
(2) As the message passes through the enclave's gateway to the outside world
it is encrypted using PEM. However, this does not change the header.
(3) Some MIME agent picks up the message externally thinking it is a MIME
message (it is clearly labelled as such). It does not see the encryption
for what it is and gets totally confused.
Now, in the first scenario you'd could claim that the MTA should not have
stamped the message as being MIME when it didn't start out that way. I would
tend to agree with this assessment and I would not implement this way. (I also
know of some MTAs that will do this that are already deployed.) However, the
author of the MTA code in question points out that RFC822 clearly states that
messages can be assumed to be ordinary ASCII text, so the MTA is really on
reasonably firm ground when it converts this to the MIME equivalent.
You can find similar things to criticize in the second scenario and they have
similar rebuttals. And other scenarios are possible. However, my purpose here
is not to quibble, assign blame, or point fingers. My purpose is only to expose
a developing situation that I think is going to cause problems. I'd like to
prevent this from happening if at all possible.
The simple approach you describe
could be used to transport PEM messages in MIME, but we are looking
for a comprehensive set of specs on how to encapsulate PEM in MIME and
vice versa, which will take some effort.
I am in complete agreement with the effort to do all this comprehensively, and
I am willing to actively participate in this development if necessary in order
to get it done. In particular, this work will fill in what I regard as the
single biggest gap in MIME -- the lack of a message integrity check.
However, I think that by even the most charitable estimate this work is going
to take a fair amount of time. The simple approach of defining an
application/pem or message/pem or whatever, on the other hand, could be
standardized quickly and would effectively eliminate all the interoperability
problems I can think of.
I therefore think that the simple approach has real merit in the short term. If
PEM implementations could be asked to add two headers to PEM messages
(MIME-Version: and Content-Type:) we can get deployment started without
interoperability problems. And once a more comprehensive framework is developed
we can replace this interim solution with the more comprehensive approach.
What do we lose by doing this? Well, we will have deployed a form of PEM/MIME
that will eventually become an albatross that everyone will have to support but
nobody should ever use. But is this any different than the deployment of
PEM-without-minimal-MIME-headers we're already talking about doing? I'm fairly
certain that any comprehensive MIME/PEM solution will involve abandoning
current usage in one way or another. So modulo two small headers I cannot see
any difference.
I therefore propose that the Working Group register a MIME subtype and start
using it for the current PEM work. This lets PEM coexist happily with MIME
until such time as a more comprehensive merger can be worked out. It should be
clearly understood that this is an interim solution until a merger has been
completed. I think there's a lot to be gained by such an approach and almost no
disadvantage to it.
This may also have a very beneficial side effect. By registering a MIME subtype
for PEM you are effectively communicating with the rapidly growing MIME
development community. You are saying that MIME now includes a privacy enhanced
facility that MIME implementations should support if they intend to be
reasonably complete. I cannot help but think that this will assist in getting
PEM deployed, and in fact it may result in fairly significant deployment that
would not have happened otherwise.
Ned