Oh God No.
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
be ASN.1).
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.
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). 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.
Jim
-----Original Message-----
From: smime [mailto:smime-bounces(_at_)ietf(_dot_)org] On Behalf Of Paul Hoffman
Sent: Wednesday, April 30, 2014 9:26 AM
To: smime(_at_)ietf(_dot_)org
Subject: [smime] eContentType for detached signatures
Greetings again. An issue has come forth that significantly affects S/MIME,
specifically detached signatures. It would be good if this group (which
hasn't been a WG in four years) could weigh in on the topic.
RFC 5485 describes how to use S/MIME detached signatures to sign Internet
Drafts. That RFC was not produced by this group, and was barely discussed
here at all. (There was a two-day discussion under the subject of "Please
review draft-housley-internet-draft-sig-file-00.txt"). That RFC makes a
significant change to detached signatures in that it make the eContentType
define the type of document that is being signed, and names four content
types, none of which are formally defined. If you look at the table labeled
"SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" in
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-26
, you see that those four types are the only non-security types in the
table.
The rationale at the time for this design choice was approximately "a
detached signature over a file that has no MIME information needs to specify
the content type of the file". The files being signed in RFC 5485 don't have
any MIME information, so RFC 5485 created CMS content types for them.
Note that any file can have detached signatures, not just the four types of
files named in RFC 5485. RFC 3852, our standard, talks a bit about detached
signatures:
The optional omission of the eContent within the
EncapsulatedContentInfo field makes it possible to construct
"external signatures." In the case of external signatures, the
content being signed is absent from the EncapsulatedContentInfo value
included in the signed-data content type. If the eContent value
within EncapsulatedContentInfo is absent, then the signatureValue is
calculated and the eContentType is assigned as though the eContent
value was present.
Nothing there says to me that the eContentType should be usable by a
receiving party to know what the inner content type is. There was no concept
of that in any of the three versions of the CMS standard.
To me, RFC 5485 took the wrong path. It should not be required that every
time someone wants to create a detached signature over a file, they need to
register a new CMS content type. Instead, there should be one eContentType
for detached signatures that is defined as "inner content type is
undefined". An alternative would be to create OIDs for everything in the
MIME registry, but this seems excessive and of little value.
Thoughts appreciated.
--Paul Hoffman
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime