Arun,
I don't think this is a problem of loss of information, because
whatever information is sent is received in the content. In the
scenario you describe, I think it is likely that the content would be an
RFC 822 (2822?) message. So provided that the recipient can decode such
content, all information that the sending client intended gets through
okay. While I don't think most X.400 UAs today will decode RFC 822
there are some that will, and I strongly believe that we should support
that scenario for architectural reasons.
I would not be totally adverse to having a statement like those in
2633bis that says, "the sending client MAY wrap a full MIME message in a
message/rfc822 wrapper in order to apply S/MIME security services to
these headers." However, it should be noted that this adds no
requirements (it's only a MAY). Also, I'm not sure where to place such
a statement in X.400 transport; it's kind of out of scope.
However, it is important to note that X.400 transport does not
REQUIRE that the innermost content be in the RFC 822 format. That is
one reason that we don't want to make any strong associations to IPMS
content. As the documents stand, three scenarios are supported:
- CMS protected X.400 content (not necessarily IPMS),
transferred over X.400
- CMS protected X.400 content, transferred over SMTP
- CMS protected RFC 822 content, transferred over X.400
- CMS protected other (non-822 MIME or non-MIME content),
transferred over X.400
The problem here is that I think we want to say as little as possible
about content translation. These drafts (and S/MIME in general)
fundamentally don't profess to provide translation, only secure
transfer. Our scenario is that we assume that both the X.400 and SMTP
communities will agree to use a common content for interoperability
sake. Hence the caveats in the 2nd and 3rd paragraphs of the
introduction. Admittedly, this has caused a little friction in the
IESG, but in the end I think they agreed that this is the least painful
of several unattractive alternatives. You can't have MIXER-style
translations AND end-to-end security.
Regards,
Chris
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Pandey,
Arun
Sent: Friday, June 06, 2003 07:33
To: ietf-smime(_at_)imc(_dot_)org
Subject: Loss of Information while mapping an Internet S/MIME Message to
X.400.
Hi,
As per draft-ietf-smime-x400transport-07.txt:
"When transporting a CMS-protected message in X.400, the preferred
approach is to
convey the object as X.400 message content. Implementations MUST include
the CMS
object in the content field of the X.400 message."
However when mapping an Internet S/MIME message to an X.400 Message:
1. The CMS object is placed in the X.400 Message Content (as
recommended).
2. The RFC 822 header fields of the Internet message that can be mapped
directly
to the X.400 envelope fields are placed in the X.400 Message
Envelope.
3. This leaves out the Internet Message header fields that are normally
mapped to
the IPM Content Heading fields. In the X.400 Content carrying the CMS
object
there are no corresponding fields for them. As a result such fields
apparently
cannot be mapped to the X.400 message and will be lost (on conversion
from
Internet to X.400 message). Such fields are :
Subject, From, To, Reply-to, In-reply-to, Message-id, cc, bcc,
Sender, Expiry-
date, Deferred-delivery-date, Latest-delivery-time, Importance,
Sensitivity,
Language and References.
How can this loss of information be avoided, what is the recommended way
around
this particular problem?
The possible workarounds could be:
1. The Internet User Agent constructing an S/MIME message SHOULD place
the
message content along with these fields into a Message/rfc-822
content before
securing it. This should be done if these fields are desired to be
seen by
the receiving user agent (in case the message is to be transported
over an
X.400 network.)
But I found that existing applications like Microsoft Outlook do not
provide
an option to perform an Message/rfc-822 wrapping of these fileds.
2. Another solution could be to map the CMS object in an IPMS content,
wherein
the above fields could then be mapped to the IPMS content heading
fields, and
the CMS object could be placed in an appropriate bodypart (ftbp with
file type
as smime.p7m).
But this goes against the recommendation "Implementations generally
SHOULD
NOT embed CMS objects within X.400 body parts, but should instead
convey them
as content as described in sec. 2.2" of
draft-ietf-smime-x400transport07.txt.
Best Regards
Arun Pandey