On Apr 30, 2014, at 10:15 AM, Jim Schaad <ietf(_at_)augustcellars(_dot_)com>
Oh God No.
Tell us what you really think, Jim. :-)
It has been my contention for a long time that the S/MIME group made a
mistake by not defining a new content type for S/MIME messages which was
id-ct-mime to allow for a processor to know that there was mime content
inside rather than some unknown binary or text object (which happened to not
That suggestion would be fine; it is also unrelated to the current topic. We
are talking about detached signatures on things that are not MIME-wrapped
What RFC 5485 did makes perfect sense to me and always has. I completely
disagree that there is any indication that the econtentType does not give an
indication of what the inner content is, that is the complete purpose of the
field. The definition of eContentType is
eContentType is an object identifier. The object identifier uniquely
specifies the content type.
It does not say that this is how to know how to decode it - it says is
uniquely specifies the content. (And probably really should say content not
content type.) There is nothing here that says it needs to be an ASN.1
content for new OID values.
My proposal meets that definition. It specifies that the inner content type is
One needs only to define a new content type for those things which need
special handling before they are processed. This is true for some contents
defined in RFC 5485 (asciiTextWithCRLF and xml).
I'm not seeing what is the "special handling" needed for the detached
signatures defined in RF 5485. That may be were we diverge so severely.
When you are validating a detached signature, what is the special handling
It may be convenient to do
this for contents that are different and have no easy internal
identification (this is true for the pdf and postscript types defined in RFC
5485). For mime, one would need, at most, to define one which would be
id-mime to say that mime is embedded. If one wanted to directly include the
content, without the mime wrapping, then yes, one could defined a new CMS
content type for that purpose. I think one would probably get pushback from
the expert reviewers in this case (I know that I would) unless there
appeared to be a good reason for dropping the mime wrapping.
Again, this thread has nothing to do with MIME-wrapped content.
smime mailing list