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