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
[email protected]
https://www.ietf.org/mailman/listinfo/smime