Chris,
It seems we agree about almost everything except discussing compatability with
STANAG 4406 PCT. I'm surprised by your response on this, since I had assumed
that such compatability was an unstated goal of your drafts. If compatability
is accidental, it is fortuitous! But even so, I don't really see why you don't
want to acknowledge it. Whether or not IETF is mightier than NATO is
irrelevant. NATO published three years ago, and there are now implementations
of PCT in the market. Therefore, you should be discussing compatability with
existing product implementations.
Detailed comments embedded below.
Jim
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.
In the X.400-to-SMTP direction a MIXER gateway could quite legitimately reject
(i.e. non-deliver) any content-type other than IPMS.
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.
I think the mapping rules for the more general X.400 to SMTP gateway need to be
along the following lines.
For X.400 to SMTP, apply one of the following according to the X.400
content-type:
- for content-type IPMS (2 or 22), apply MIXER in full.
- for any content-type for which a mapping of the content is defined, apply
that mapping [I'm not aware of mappings having been defined for any other
content-type, but we shouldn't preclude someone producing a mapping for EDIM,
or Military-messaging, or Voice-messaging, or some other content-type].
- for content-type contentInfo, take the X.400 content and apply a MIME
transfer encoding (e.g. Base 64) and inserted it into an application/pkcs7-mime
MIME entity, setting the smime-type from the EITs (exactly how requires
specification), create the vestigial RFC822 Header (section 5.3.2 of RFC2156),
and map the X.400 envelope as specified in various parts of RFC2156 (I too
thought that it would be easy to specify which part until I looked at the
inter-twined tangle of envelope and content in RFC2156). Where the content
within the content-info is ultimately an RFC822 message, there will need to be
a flag somewhere in the CMS to indicate that the outer Header is to be ignored
- otherwise the receiving agent cannot tell whether the entire message is
protected, or whether a protected message has been forwarded without further
protection.
- for any other content-type, take the X.400 content and apply a MIME transfer
encoding (e.g. Base 64) and inserted it into an application/x400-content MIME
entity, setting the content-type parameter from the value in the X.400
envelope, and create the vestigial RFC822 Header and SMTP Envelope as for
content-type contentInfo. [The alternative to this option is that the gateway
rejects the message with a non-delivery report for unsupported content-type,
and it would seem bizarre to allow the content-type if protected by CMS but not
otherwise.]
For SMTP to X.400:
If the message contains a Header with a single MIME entity:
- if the MIME entity is application/x400-content then strip the MIME transfer
encoding and place the result into the X.400 content, setting the content-type
from the content-type parameter, and map the Header and SMTP Envelope into the
X.400 envelope (as specified in various parts of RFC2156), and discard any
remaining Header fields.
- if the MIME entity is application/pkcs7-mime *and* either the smime-type is
signed-x400 or enveloped-x400, or for other smime-types the "complete message
protected" flag (to be defined) is present, then strip the MIME transfer
encoding and place the result into the X.400 content, setting the content-type
to contentInfo and the EITs <to be specified>, and map the Header and SMTP
Envelope into the X.400 envelope (as specified in various parts of RFC2156)),
and discard any remaining Header fields.
- otherwise, apply the full MIXER mapping, but map any application/pkcs7-mime
or application/x400-content MIME parts into ForwardedContent body-parts.
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.
I am proposing the above only when the inner content is an X.400 content type,
not when it is RFC822. I thought that adding this to X400WRAP and not to
X400TRANSPORT achieved that aim.
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?
Yes, I'm happy with that.
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.
The drafts do not clearly specify conformance requirements. If you intend to
require reception of an X.400 content protected by CMS over X.400 transport
both where the CMS object is covered by an outer MIME wrapper and also where
the CMS object is not covered by an outer MIME wrapper, then all receiving
systems have to have a layer between the X.400 transport and the X.400 or
S/MIME agent to add (or subtract) the MIME wrapper [assuming your S/MIME agent
to be inflexible and require (or not) the MIME wrapper}. It seems more
straightforward to me to apply this layer if required on the sending side (to
remove the MIME wrapper if necessary - though most CMS implementations can be
configured not to generate it) so that only one option is sent - the more
efficiently encoded one - and all receiving systems add the MIME wrapper if
required (though again frequently it won't be required). The need to add a MIME
wrapper layer or not then becomes governed by the implementation capabilit!
ies, and can be limited to cases where it is needed rather than having to be
part of every implementation.
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.
Well currently x400transport says "Sending agents SHOULD include the
appropriate S/MIME EIT OID value." - to me, "the value" is singular. Allowing
multiple EIT values, one for each protection type (signed or enveloped)
present, and one containing the OID representation of the inner X.400
content-type, certainly provides a solution. I don't immediately see how to map
reversably between these multiple EITs and the application/pkcs7-mime
"smime-type" parameter, however.
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.
I agree that there is no need to distinguish triple-wrap from more arbitrary
nesting of both signed and encrypted.
Jim