Hi Jim,
I'm glad to have your input on this. Some responses are embedded below.
Chris
On Wed, 30 Jan 2002 14:11:36 +0000, Jim Craigie
<Jim(_dot_)Craigie(_at_)clearswift(_dot_)com> wrote:
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.
I'm becoming convinced of this too. I guess I imagined that the distinction
between envelope handling and content handling was self-evident enough to not
have to connect the dots. However, if we're going to explicitly cite MIXER, I
guess we need to tighten this down. Harald Alvestrand has pointed out that the
default behavior that we desire (i.e., leave the content alone) is not made an
option in MIXER. This probably wouldn't be a problem in the X.400-to-SMTP
direction, but for SMTP-to-X.400 it would probably result in a HARPOON
encapsulation being performed. This would be unfortunate, because it would
yield multiple behaviors for receiving UAs in the X.400 world to consider.
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.
I somehow thought this had been dealt with (it was certainly discussed), but
I see that it is absent in the document. I agree that it needs to be
considered.
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.
This seems okay to me. I can see that if a UA is going to sometimes send
CMS-protected X.400 content, it is reasonable to guess that it's sometimes
going to send unprotected X.400 content. However, I can see how it might be
controversial. At present, we're only considering CMS-encapsulated X.400
content that might ride over SMTP. A MIXER gateway would probably ignore that
combination on the way out of X.400. If we add this we're recognizing that
*SOME* X.400 messages should be MIXER converted and some not. How is the
gateway to know? Granted that most gateways are local, so maybe this isn't a
serious problem. I guess we need to elaborate all the permutations of this to
see how it shakes out.
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.
For RFC 2632, I agree. See below.
As regards, STANAG 4406 - I think that's just a private spec as far as IETF
is concerned. Also see below.
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.
I think I need to spend some time pondering the implications of this, but I
think I might agree. At the outset, I was thinking that most scenarios would
employ an SMTP equivalent to an X.400 address. However, I guess this isn't
always the case. I am a little concerned that we might need to tweak this a
little because we'd like the CMS/MIME-over-X.400 configuration to be able to
interoperate with S/MIME clients that do not otherwise conform to X400WRAP.
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.
I strongly disagree with this statement. PCT is essentially a private
adaptation of S/MIME. It's not standardized in IETF, and I don't think it
merits consideration here. If something needs to be done with PCT, then I
think they should handle it in STANAG 4406. It's really out of scope of IETF.
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.
We tried to avoid calling these objects S/MIME messages, because in this
context they might well contain X.400 content (which clearly DOES NOT comply
with RFC 2633, hence it's not "S/MIME"). Maybe we can say, "a CMS object
containing a complete message". Does this work?
I would think, btw, that something like an Excel spreadsheet would appear as
an attachment within the message. However, I take the point that we're only
talking about messages here; not non-message objects.
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!
This was not an attempt to add an option, but merely to recognize reality
that this variation would occur. One of the reasons we split this spec was to
allow different configurations, such as:
- CMS(MIME)-over-X.400
- CMS(P2)-over-X.400
- CMS(P2)-over-SMTP
By separating X400transport, we've expressly allowed the possibility that
this MIGHT be used with an off-the-shelf S/MIME agent that provides the content
with an wrapper already applied. In the case where MIME-based S/MIME is just
tunneling through an X.400 transport, this makes the most sense. Rather than
stipulate that this must be removed (and where?), we simply indicated an
appropriate existing identifier.
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!]
Okay. I'm always in favor of deleting extraneous 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.
I think you misunderstand. These values need not be exclusive to other EIT
definitions. So you could have the EIT id-eit-envelopedx400, and also EITs
from X.420. Perhaps this could be made clearer in the text.
As for distinguishing between signed and triple-wrapped, I think it's only
necessary to include both the id-eit-envelopedx400 and the id-eit-signedx400
EITs. The receiving agent would be able to see that it handled both. Since
arbitrary nesting seems to be shaping up as a basic requirement for reception,
indicating triple-wrapping per se isn't really necessary. There was some
push-back to suggest that we didn't need signed-x400 and enveloped-x400, and
that signed-data and enveloped-data was sufficient. Personally, I am happier
to have the additional types because it provides more information in the event
that it is the only EIT.
Jim