ietf-smime
[Top] [All Lists]

RE: EITs in the x400-transport draft

2001-08-22 12:48:13

Graeme,

Comments in-line

-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Graeme Lunt
Sent: Wednesday, August 22, 2001 9:36 AM
To: 'jimsch'; ietf-smime
Subject: RE: EITs in the x400-transport draft



Jim,
 
Based on the conversations that were held in London about propigating
smime-types up.  

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.

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.

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
manysecurity services.  This also eases the code in moving
SMIME-types 
from layer to layer.

Do I take it then that is to be a new draft in the (near) future?

[JLS]  I am sure that a new draft will be published before the last call
is completed, but as I am not an author on the draft I cannot really say
what will happen.

Thanks,

Graeme


<Prev in Thread] Current Thread [Next in Thread>