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