Sorry that I did properly clarify all of my points in my first post.
I can appreciate why you prefer to use S/MIME headers with binary
transfer encoding in the data of CMS-SignedData structures. To be
honest, I planned to do the same as well, especially since it is
able to interop with countless existing S/MIME applications and
opensource libraries such as OpenSSL that have S/MIME support. But
as you mentioned, we both have different requirements for our CMS
applications, and for me I need to support detached signatures.
But Chris Bonatti's suggestion of specifing the MIME-type in the
contentDescription of a ContentHints signedAtrribute in a CMS
structure would be benifical to both of us, and everyone else as
well. It is a win-win for all!
For your CMS signedData structures with S/MIME headers and binary
transfer encoding, you could specify in the ContentHints attribute
a specific a MIME-type such as:
or Content-Type: application/pkcs7-mime
that would instruct the CMS software that it needs to parse the
S/MIME text headers in the core data being signed. My CMS signedData
structures could specify a different MIME-type in the ContentHints,
so the CMS software would handle it as well. Everybody wins!
(BTW I am not sure what the correct MIME-type is for your
case, I only selected the above MIME-types as an example.)
It looks like the contributers to the S/MIME standard had this in
mind when they conceived of the ContentHints attribute. Still, do
to the vaugeness of the contentDescription, I would love to see any
sample contentDescription text that people are current using.