Blake,
To me, this makes sense. Even if it isn't required in an S/MIME
message, it stands to reason that other CMS wrappers might be used. We
don't actually prohibit their use in S/MIME do we?
I'm wondering if this is starting to look like misplaced text.
Originally, it made sense to have MIME types in the message spec, but
now we also have them in the X.400 transport spec, and apparantly some
that don't fit neatly anywhere. Maybe this should have been rolled back
into CMS. (I know it's too late for that.) Short of that perhaps the
best strategy is to repeat the whole list everywhere that it appears.
Regards,
Chris
On Thursday, June 19, 2003, at 8:14 PM, Rohan Mahy wrote:
On Thursday, June 19, 2003, at 03:50 PM, Blake Ramsdell wrote:
-----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 Rohan
Mahy
Sent: Friday, June 06, 2003 7:59 PM
To: Blake Ramsdell
Cc: ietf-smime(_at_)imc(_dot_)org; rohan(_at_)cisco(_dot_)com
Subject: proposed addition to application/pkcs7-mime smime
parameter
I have included some proposed text to add the other CMS
types to the
smime-type mime parameter. Alternatively a new cms-type mime
parameter could be defined, but this seems a but pedantic to me.
We are in a strange situation here, and I'd like to get feedback on
this. One side of me says that the "application/pkcs7-mime" means
"MIME packaged in PKCS #7 (which then became CMS) for the
purpose of
moving around secured MIME entities". I don't know if it's
a better
idea to
a)
overload the application/pkcs7-mime type to mean "CMS, possibly not
wrapped in MIME", or b) introduce application/cms in a
separate draft,
along with a cms-type parameter that explains the inner type.
I'm not sure what you mean "not wrapped in MIME" here. In
all the SIP
cases at least, we are always talking about taking some MIME content,
performing some CMS operation on it, and putting the
resulting CMS blob
in a MIME body. There are only three things different here:
- we are not restricted to out MIME bodies being 7-bit... they can be
binary, but they are still MIME. I still need to have insure that my
--boundaries don't appear in my content for example.
- we can use attached signatures. since we have a negotiation
mechanism, if the UAS doesn't understand application/pkcs7-mime, its
can send a repairable error response (hey! I can't read this content
format) and the UAC will either send a different MIME type or give up.
- because some pairs of SIP entities already have shared secrets
(because of their digest legacy), we would like to used
AuthenticatedData instead of SignedData in some cases. If email
clients already had shared secrets, you might have done that in email
too, so there is really nothing special about this.
I don't think any of these things change the semantics of the
MIME type.
I'll ping some friends who are active in the APPS Area as well, but I
don't think I am too out of line here.
thanks,
-rohan
I know that there was much discussion about application/xml in a
similar
context, and I don't know if there's anything we can learn
from that in
order to resolve this. It seems that the application/xml semantic
would
be very similar to the application/cms semantic, but I may not
understand it correctly.
I'm going to release 2633bis-05 shortly, and if there's no
discussion
on
this topic I'm not going to include anything in that draft. If it's
important, we should work through it.
Blake