On 27 December 2001 Chris Bonatti wrote:
As Russ reported at the meeting in Salt Lake, the IESG has expressed
some concern that we address the relationship (or lack thereof) between
the CMS-X400 specs and the MIXER standards. The MIXER document (RFC
2156) and the BODYMAP document (RFC 2157) specify how to perform
gateway translations between SMTP/MIME and X.400 envelope and P22
content. The IESG's concern seemed to arise from the fact that the
X400WRAP and X400TRANSPORT drafts dealt with mixtures of X.400 and MIME
objects, but did not give any consideration to the only other RFCs that
did so. This seems to be a reasonable concern.
Fortunately, the possible interaction between our drafts and the
MIXER standards is very limited. Obviously, in the case where you're
dealing in signed or encrypted content, the application of gateway
translations cannot affect the content without first removing the CMS
wrappers. In the case of the X400WRAP draft, any translation is simply
out of scope. In the case of the X400TRANSPORT draft, gateway
translation of the envelope only is fully possible without interfering
with the security services. However, the translations (and MIXER)
remain orthoganal to our work.
In this light, I have been considering some additional text to make
this situation clearer in both documents. As a result, I propose the
following amendments to the document draft-ietf-smime-x400transport-04:
- Append a new 2nd para to "1. Introduction"
This document describes a mechanism for using CMS objects in
an otherwise native X.400 environment. It describes an
environment that deliberately uses a mix of technologies, but
does not describe any gateway operations, per se. It is
possible to combine the provisions of this document with
gateway operations, such as specified in [MIXER]. However,
translation must be limited to the envelope fields only since
modification of the CMS-protected content would invalidate
S/MIME security services.
- Add to the "A. References" section:
[MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998.
Also, I would propose the following amendments to the document
draft-ietf-smime-x400wrap-04:
- Append a new 5th para to "1.1 Specification Overview"
This document describes use of security services for X.400 content
that will not interact well with gateway services, such as described
in [MIXER]. Translations limited to envelope processing may be
viable in the context of this document. Body translations, such
as described in [BODYMAP], cannot be performed without removing
S/MIME security services. Translation after removal of the CMS
security measures described herein is beyond the scope of this
document.
- Add to the "A. References" section:
[MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998.
[BODYMAP] Alvestrand, H., Editor, "Mapping between X.400 and
RFC-822/MIME Message Bodies", RFC 2157, January 1998.
I look forward to any feedback on this approach, or on my specific
proposed text.
Best holiday wishes to all,
Chris B.
Chris,
Sorry that it has taken so long for me to find the time to reply.
As you note in your message, RFC2156 explicitly limits its scope to the X.420
Interpersonal Messaging System, and "not to wider application of X.400". Your
text for inclusion in the drafts should state this.
Since RFC2156 does not specify how to gateway X.400 content types other than
IPMS, it is not sufficient to say "translation must be limited to the envelope
fields only " - unless you spell out the detail implementors will not produce
consistent behaviour. Your drafts (or an addendum to MIXER) need to state
precisely which parts of RFC2156 are applicable when gatewaying of the content
types defined in x400transport and x400wrap is to be performed.
X400wrap fails to mention that when the objects it defines are transported over
SMTP transport there will of necessity for conformance to RFC 2822 be a
vestigial Header. This will comprise at a minimum the mandatory Header fields
specified in RFC 2822: "From:" and "Date:". If it is intended that these fields
(which duplicate semantics already contained within the X.400 content within
the wrapped object, but are not derived from them) are to be ignored on
reception then this must be stated explicitly. If this is the case, then the
values in these fields on origination can be arbitrary. Given this additional
specification, gatewaying of the x400wrap content is straightforward, but does
need to be specified.
Neither your drafts (quite reasonably) nor any other RFC that I can find
specifies how an X.400 content (without CMS protection) can be conveyed by SMTP
transport. For completeness, could this be included in x400wrap? I propose:
Content-Type: application/x400-content; content-type = 1*DIGIT *( "." 1*DIGIT)
where the content-type parmeter value is either a single integer (for a
built-in content-type) or an OID in dotted notation (for an extended
content-type).
Either your drafts or a separate addendum to MIXER can then specify simple
gatewaying rules at the message transport level for any X.400 content-type,
defaulting to the above for a content-type for which no other mapping is
defined.
Having reviewed your drafts again, I have several additional comments.
X400wrap also omits mention of two other documents that it affects: RFC2632 and
STANAG 4406.
X400wrap omits mention of changes to requirements on Certificates. It should
state that for this content the following wording replaces the second and third
paragraphs in section 3 of RFC2632:
Receiving agents MUST recognize X.400 addresses in the subjectAltName field.
Sending agents SHOULD make the address in the Originator or Authorising User
heading field in a wrapped mail message match an X.400 address in the
signer's
certificate. Receiving agents MUST check that the address in the Originator
or Authorising User heading field of a mail message matches an X.400 address
in the signer's certificate, if X.400 addresses are present in the
certificate. A receiving agent SHOULD provide some explicit alternate
processing of the message if this comparison fails, which may be to
display a message that shows the recipient the addresses in the
certificate or other certificate details.
The combination of X400wrap and X400transport should address compatability with
the PCT format defined in STANAG 4406 version 3. In particular, PCT defines
both a wrapped and a "clear-signed" encoding of its signature. The latter is
particularly useful as it allows signatures to be introduced whilst preserving
interworking through backwards compatability with systems that do not
incorporate support for PCT. PCT has a major asset in that it is an algorithmic
mapping between the two encodings: thus a signature generated for one encoding
can be mapped in transit into the other encoding preserving the signature of
the originator.
Other comments on X400transport:
1. Section 2.2 first sentence:
Replace "a CMS object" by "an entire S/MIME message".
Rationale: CMS protection can be applied to objects which are not S/MIME
messages. X.400 message content certainly would not be the preferred (or even
an appropriate) approach to transporting e.g. a CMS protected Excel spreadsheet
file in an X.400 environment.
2. Section 2.2
I cannot see the purpose of introducing the X.400 content-type for a CMS object
covered by an outer MIME wrapper. It seems to me to introduce an option which
adds no value, since the MIME wrapper can be added or subtracted as needed
(e.g. when gatewaying to SMTP transport) without affecting the CMS object.
Options which add no value should be avoided!
3. Section 2.3:
Comment 1 applies here too. In addition, while in theory you could define X.400
content types to make the assertions in the third and fourth sentences true,
they are untrue in practice. It would be better to be positive and state that
for transporting an entire S/MIME message an X.400 content is more appropriate
than an X.400 body-part (except when forwarding). [I agree with your proposal
to use X.400 content - currently a sound proposal is spoilt by dubious
rationale!]
4. Section 2.5:
The defined mechanism does not seem to supply enough information on the
envelope about a wrapped X.400 content. I don't see any way to identify the
actual X.400 content-type that is inside, nor do I see how to distinguish
signed-x400 from triple-wrapped-x400.
Jim