[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re(2) : AS{035}2, MIME {038} X.400
Rik Drummond (drummond@xxxxxxxxxx) wrote:
: Our initial assumption was the same that pkcs#7 would solve the problem
: because it is opac to the smtp gateways, however the Internet power that
: be felt very strongly that we should us multipart/signed unstead of
: pkcs#7 sign in our standard. This exposes the mime object structure to
: gateways and causes the problems detailed below.
There is no inherent incompatibility with X.400 and multipart/signed. Any
X.400 gateway that alters the inner contents of MIME (or PKCS) signature
wrappers has a bug and needs to be fixed. Few gateways will have this bug
as most don't unwrap and reformat MIME at all. The ones that do must
insure it's done properly. I think the problems are overblown. Using PKCS
isn't a good solution to fixing X.400 gateway bugs.
The real answer is that if an X.400 converts EDIINT security protocols
into X.400, it _must_ be smart enough to know that it cannot tamper
with the content of signed data no matter what the format is. This
applies equally to PKCS or MIME multiparts, and either could be
equally munged. The same "bug" could exist in PKCS7 or mime multipart,
so that isn't a justification for using PKCS7.
Any encrypted message will be opaque no matter what encryption format is
used. That's the best workaround, should a bug arise. There are plenty
of X.400 gateway bugs to go around, so there is no need to feel special
about this case.
Probably most Internet EDI systems will not want the MIME bodies
converted into X.400, since software would be written only for MIME
rather than MIME + X.400. A gateway that converted MIME might cause
the EDI interface to fail.
--------------------------------------------------------------------------
Carl Hage C. Hage Associates
<mailto:carl@xxxxxxxxx> Voice/Fax: 1-408-244-8410 1180 Reed Ave #51
<http://www.chage.com/chage/> Sunnyvale, CA 94086