Your correct. However I was specifically referring to RFC 1327
gateways, which at the current time are not aware of multipart/signed
messages. This means, and implementation of RFC 1327 is perfectly
allowed to split a MIME message into its components, and then rebuild
them, but there is nothing to say the MIME headers have to be built in
the same order. If the order is different the signature fails.
The next verson of RFC 1327 - MIXER, needs to be aware of
multipart/signed messages, and pass the message through untouched. This then
leaves the X.400 User Agent with the task of interpreting the MIME
body part after signature verification. This should not be too
difficult.
Not necessarily. It seems the primary point I was trying to make has been lost,
so let me restate it: There is no "right way" or "wrong way" here. Sometimes it
is appropriate to tunnel multipart/signed. Sometimes its appropriate to dissect
it and the hell with the signature. Sometimes its appropriate to check the
signature at the gateway, discard it, and translate the signed content. You
cannot mandate any one behavior because there are perfectly valid and
realistic scenarioes where any one behavior will be absolutely unacceptable.
I realize that MIXER has always tended towards tight specifications with a
minimum number of options, but this a case that's very similar to the
discussion of the use of global ORName mappings we had some time back --
sometimes global mappings are appropriate and sometimes they aren't, and you
cannot simply legislate their use into existance at many if not most sites.
The best you could do would be to follow the philosophy that's now being
applied to the global mapping issue and require gateways to allow for either
tunneling or stripping, and recommend that they also implement signature check
as an option if at all possible.
The other alternative for MIXER is to push multipart/signed messages
into X.400 file transfer body parts. This makes it easier for the
X.400 user agent, and it will often use external processes for these
anyway, so in this case, it could invoke the MOSS interpretor process.
Insofar as this discussion goes this is just another form of tunneling. But it
rings up the separate issue of how to handle untranslateable MIME objects. I
agree with you that FTBP needs to be looked at as a means to do this.
Ned