Subject: EITs in the x400-transport draft

From: "Jim Schaad" <[email-masked]>
Date: Wed, 15 Aug 2001 12:11:43 -0700

Based on the conversations that were held in London about propigating
smime-types up.  I would like to propose that we remove enveloped-x400
content and signed-x400 content EITs and replace it with x400-content
EITs and S/MIME types.  This is a difference from the SMIME-types from
the message draft, but in retrospect I believe that knowing the content
is of more importance that trying to one of the potentially many
security services.  This also eases the code in moving SMIME-types from
layer to layer.

Jim

---

From: Graeme Lunt <[email-masked]>
Date: Tue, 28 Aug 2001 10:55:26 +0100

Jim.

> > Could you perhaps summarize these conversations for me?
> > I did not attend the last IETF meeting, and my colleague who did
> > attend the S/MIME meeting does not have detailed notes.
> 
> [JLS]  This topic started on the list before London, basically I was
> have started to argue that the S/MIME type should generally tell you
> what the inner most content type is rather than trying to tell you what 
> this security layer is.  (I.e. map to the inner-content type attribute
> not to the contentInfo OID.)  I raised this question because I did not
> know what the S/MIME type of a signed-receipt should be if a layer of
> encryption is added to the message.  I started this line of reasoning
> based on the EITs of the X.400 world.

Thanks for the summary.

> > > I would like to propose that we remove enveloped-x400
> > > content and signed-x400 content EITs and replace it with 
> > > x400-content EITs and S/MIME types.  
> > 
> > Does this have any bearing on my comments I sent to the list about 
> > the EITS, and in particular being able to identify the inner X.400 
> > content type (e.g. P22 over P772)?
> 
> [JLS]  No, I don't remember seeing this comemnt, however it 
> would have a potential bearing on this.  The question would be should 
> all x.400 content be seen as one and the same or as different things.  
> Different things would argue for different EITs and different SMIME-Types.

> I have absolutely no preference on this issue.

Here is a repost of what I sent to the list - I did not get any feedback.

----

In terms of the EITs, it would be much more useful if the EITs for 
"wrapped X400" messages could indicate the actual X.400 content type that 
is wrapped.  Indicating to a UA that it will find X.400 rather than MIME 
is useful but if the UA then finds EDI (or even unidentified content) 
inside when expecting P22, then it hasn't really gained much.

It would be more useful if the EITs available were something like (in
smime-type notation):
signed-x400-p0
signed-x400-p2
signed-x400-p22
signed-x400-oid.<oid> (for external content types).

For X.400 EITs OIDs, you could use a OID concatenation method (as used
for ForwardedContent bodyparts) on id-eit-signedX400/id-eit-envelopedX400
for
external content types. 

The main requirement I see is for a distinction between p22 and external
content types.

This provides me with more information about the internal X.400 content that
I am likely to find, and allows user agents to choose the appropriate form
for displaying the encapsulated content type.

This provides the same information as the contentHints.contentType ESS 
extension, but is available to the MTS. The MTS could then act on this EIT 
e.g. in a military environment, CMS wrapped P772 messages could be 
identified over CMS wrapped P22 messages.

----

It is a slightly different point, but ultimately trying to get useful 
information from the inner-most content type. In the X.400 world, I 
would just like to have an EIT for
* signed
* enveloped
* receipt
* P22
* P772 
* ... (other content types)

- that is one EIT for the inner-most content type plus one or more EITs
for the services applied.

However mapping to an S/MIME type then becomes more tricky - hence the 
slightly inelegant stuff I mentioned in my previous message.

Graeme