Re(2): MIXER Impact on CMS-X400

Jim Craigie <Jim.Craigie@clearswift.com> Tue, 05 February 2002 15:43 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04711 for <smime-archive@lists.ietf.org>; Tue, 5 Feb 2002 10:43:45 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15FRmJ24746 for ietf-smime-bks; Tue, 5 Feb 2002 07:27:48 -0800 (PST)
Received: from tube.clearswift.com (tube.clearswift.com [195.153.60.158]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15FRk324740 for <ietf-smime@imc.org>; Tue, 5 Feb 2002 07:27:46 -0800 (PST)
Received: from orange.net-tel.co.uk (orange.net-tel.co.uk [193.122.171.1]) by tube.clearswift.com (4.6.0.87) with ESMTP id ; Tue, 05 Feb 2002 15:25:00 GMT
Received: from "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/" by orange.net-tel.co.uk (Route400-RFCGate); Tue, 5 Feb 2002 15:29:03 +0000
X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Tue, 5 Feb 2002 15:29:03 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Tue, 5 Feb 2002 15:29:03 +0000
X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; ORANGE:0057-020205152903-0294]
X400-Content-Type: P2-1988 (22)
X400-Originator: Jim.Craigie@clearswift.com
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Tue, 05 Feb 2002 15:29:03 +0000
X400-Content-Identifier: Re(2): MIXER Imp
Message-Id: <"BARNOUIC:0634-020205152654-0002*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
From: Jim Craigie <Jim.Craigie@clearswift.com>
To: "Bonatti, Chris" <BonattiC@ieca.com>
Cc: IETF SMIME WG <ietf-smime@imc.org>
References: <LOEILJNBHBPKGOPJCMADIELLEAAA.BonattiC@ieca.com>
Subject: Re(2): MIXER Impact on CMS-X400
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

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.Craigie@clearswift.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
> > 
> > 
> 
>