RE: MIXER Impact on CMS-X400

"Bonatti, Chris" <BonattiC@ieca.com> Mon, 04 February 2002 19:36 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 OAA03929 for <smime-archive@odin.ietf.org>; Mon, 4 Feb 2002 14:36:52 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14JBFQ08762 for ietf-smime-bks; Mon, 4 Feb 2002 11:11:15 -0800 (PST)
Received: from Obsidian (pcp794540pcs.nrockv01.md.comcast.net [68.49.88.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14JBD308756 for <ietf-smime@imc.org>; Mon, 4 Feb 2002 11:11:13 -0800 (PST)
Received: from [127.0.0.1] by Obsidian (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Mon, 4 Feb 2002 14:11:12 -0500
From: "Bonatti, Chris" <BonattiC@ieca.com>
To: Jim Craigie <Jim.Craigie@clearswift.com>
Cc: IETF SMIME WG <ietf-smime@imc.org>
Subject: RE: MIXER Impact on CMS-X400
Date: Mon, 04 Feb 2002 14:11:10 -0500
Message-ID: <LOEILJNBHBPKGOPJCMADIELLEAAA.BonattiC@ieca.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <"BARNOUIC:0744-020130140903-0005*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g14JBE308758
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>
Content-Transfer-Encoding: 8bit

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.

> 
> 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
> 
>