ietf-smime
[Top] [All Lists]

[smime] eContentType for detached signatures

2014-04-30 11:25:54
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

<Prev in Thread] Current Thread [Next in Thread>