Does anyone know of work being done for MIME-MHS gateway support for
privacy-enhanced messages? The MIME-MHS mapping Internet Draft does not
mention "multipart/pem" and "application/pem" mappings to X.400.
In at least one sense it does not need to. In particular, the handling of
subtypes not specifically addressed in the MIME-MHS document is described.
Things must be done this way because both MIME and X.400 are open and new
content type/subtypes can appear at any time.
This mechanism may not be highly elegant but it should work. If it does not
work it calls the whole MIME-MHS approach into question. However, I don't see
any problem with it at present.
It would seem that as many (or all) of the <pemhdr> fields map into the X.400
header and some <pemtext> content-types map directly to body parts, that the
direct mappings for `simple' messages and the encapsulation of complex or
nested messages should be specified for gateways.
This is probably doable, however the most straightforward mapping would be one
where the <pemhdr> fields end up in a bodypart, as does the <pemtext>. A
special message structure would then contain these two, just like multipart/pem
does in the MIME world.
There are some problem with using heading extensions though. Since different
parts may well receive different sorts of privacy enhancement (including none),
there has to be a way to associate the proper header structures with particular
parts. This isn't as easy as it looks. (Harald Alverstrand, Steve Kille, and I
struggled with this late one IETF night in relation to the Content-ID and
Content-Description MIME headers, and we finally agreed that it wasn't worth
the effort to preserve these headers.) It is unfortunate that new structures
cannot be associated with a particular bodypart without defining a new
bodypart, but that's the way it goes. (We even toyed with the idea of asking
the X.400 folks to add this, but we gave up on that fairly quickly.) I suspect
that this will eventually lead to the requirement that there be a message
structure around each separate privacy-enhanced entity to keep it all straight.
You must also take into account the issue of X.400-1984 downgrading when you do
stuff like this. In particular, heading extensions tend to evaporate on you
when downgrading is done, so the use of actual bodyparts for this that can be
mapped reasonably as per the HARPOON proposal may make more sense.
However, all this simply addresses structural issues. The issue of what PEM
actually *means* in an X.400 context isn't resolved. In particular, some
attention must be paid to the notion of mapping PEM into and out of
corresponding security services in the X.400 and X.435 worlds. I suspect that
this may well be an intractable problem, but I lack expertise to make a
definitive statement of this sort. The mail stuff I understand, the privacy
stuff is new terrain for me...
If mapping proves to be intractable, the next question to ask is what form
should PEM take in the X.400 world. There are a range of possibilities,
including the proposal you advanced, using MIME-MHS and HARPOON without special
regard to MIME-PEM, or even the designation of a new bodypart for this purpose
(which of course can contain all the necessary information). If either the
first or the last approaches are deemed appropriate I would recommend a
separate document giving the specifics. I am willing to help out on writing
the critter; if anyone else is interested please let me know.
This MHS-PEM document must deal with both plain PEM and MIME-PEM, and that's
unforunate, but there's not much to be done about it at this late date.
Ned