Subject: Re: SignedAttribute for Mime-Type

From: Alicia da Conceicao <[email-masked]>
Date: Tue, 13 Dec 2005 10:55:41 -0500 (EST)

> (You will probably get this response from others.)
> I am not sure why you need an OID.  Just specify content encoding as =
> binary in the MIME header.
> There is no mandatory requirement to base64 encode the mime content.
> In fact, it is recommended not to (except under certain circumstances) =
> since it leads to unnecessary message expansion.

Dear Tony:

Thank you for your response.  CMS requires all data content types
to be arbitrary octet strings, with the interpretation is left to
the application.  There is no requirement to use any type of
textual S/MIME headers in the data.  I attached the relevant
sections from the CMS rfc below.

Because of this, I did not impliment any type of data formating for
my CMS structures.  In fact, I specifically avoided it for several
reasons, including:

1) many signatures contained detached data, so the hash used in
	the CMS SignData structure should correspond to the core
	data itself and not include any encapsulation or headers,
	since with detached signatures, the encapsulation and
	headers could not be stored anywhere

2) identical core data can be encapsulated differently or have
	sightly different headers, which would give them different
	hashes; this would make pairing up signatures with their
	detached data nearly impossible

3) time stamp tokens, which are also detached signatures, also only
	hash the core data itself in the TSTInfo, and do not use any
	type of encapsulation or headers, since all time stamp
	tokens are used for detached data

Currently, I am using CMS for lots of thing completely unrelated
to S/MIME or e-mail.  In practice, more than 10% of the signatures
generated using my CMS software are for detached data.  It just
seems easier to simply specify a MIME type for the core data as an
attribute that would work for both attached and detached signatures.

Alicia.

=====================================================================

4 Data Content Type

   The following object identifier identifies the data content type:

      id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   The data content type is intended to refer to arbitrary octet
   strings, such as ASCII text files; the interpretation is left to the
   application.  Such strings need not have any internal structure
   (although they could have their own ASN.1 definition or other
   structure).

   S/MIME uses id-data to identify MIME encoded content.  The use of
   this content identifier is specified in RFC 2311 for S/MIME v2
   [OLDMSG] and RFC 2633 for S/MIME v3 [MSG].

   The data content type is generally encapsulated in the signed-data,
   enveloped-data, digested-data, encrypted-data, or authenticated-data
   content type.

5.2.1  Compatibility with PKCS #7

   This section contains a word of warning to implementers that wish to
   support both the CMS and PKCS #7 [PKCS#7] SignedData content types.
   Both the CMS and PKCS #7 identify the type of the encapsulated
   content with an object identifier, but the ASN.1 type of the content
   itself is variable in PKCS #7 SignedData content type.

   PKCS #7 defines content as:

      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

   The CMS defines eContent as:

      eContent [0] EXPLICIT OCTET STRING OPTIONAL

   The CMS definition is much easier to use in most applications, and it
   is compatible with both S/MIME v2 and S/MIME v3.  S/MIME signed
   messages using the CMS and PKCS #7 are compatible because identical
   signed message formats are specified in RFC 2311 for S/MIME v2
   [OLDMSG] and RFC 2633 for S/MIME v3 [MSG].  S/MIME v2 encapsulates
   the MIME content in a Data type (that is, an OCTET STRING) carried in
   the SignedData contentInfo content ANY field, and S/MIME v3 carries
   the MIME content in the SignedData encapContentInfo eContent OCTET
   STRING.  Therefore, in both S/MIME v2 and S/MIME v3, the MIME content
   is placed in an OCTET STRING and the message digest is computed over
   the identical portions of the content.  That is, the message digest
   is computed over the octets comprising the value of the OCTET STRING,
   neither the tag nor length octets are included.

   There are incompatibilities between the CMS and PKCS #7 signedData
   types when the encapsulated content is not formatted using the Data
   type.  For example, when an RFC 2634 [ESS] signed receipt is
   encapsulated in the CMS signedData type, then the Receipt SEQUENCE is
   encoded in the signedData encapContentInfo eContent OCTET STRING and
   the message digest is computed using the entire Receipt SEQUENCE
   encoding (including tag, length and value octets).  However, if an
   RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData
   type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the
   SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET
   STRING).  Therefore, the message digest is computed using only the
   value octets of the Receipt SEQUENCE encoding.

   The following strategy can be used to achieve backward compatibility
   with PKCS #7 when processing SignedData content types.  If the
   implementation is unable to ASN.1 decode the signedData type using
   the CMS signedData encapContentInfo eContent OCTET STRING syntax,
   then the implementation MAY attempt to decode the signedData type
   using the PKCS #7 SignedData contentInfo content ANY syntax and
   compute the message digest accordingly.

   The following strategy can be used to achieve backward compatibility
   with PKCS #7 when creating a SignedData content type in which the
   encapsulated content is not formatted using the Data type.
   Implementations MAY examine the value of the eContentType, and then
   adjust the expected DER encoding of eContent based on the object
   identifier value.  For example, to support Microsoft AuthentiCode,
   the following information MAY be included:

      eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }

      eContent contains DER encoded AuthentiCode signing information

---

From: "Bonatti, Chris" <[email-masked]>
Date: Tue, 13 Dec 2005 11:56:00 -0500

Alicia,

  I would think that this would be a sensible thing for which to
use the 'ContentHints' attribute (see ESS clause 2.9).  You could
use 'id-data' in the 'contentType' field and the appropriate MIME
type in the 'contentDescription'.  I realize that ESS seems to
except the data content type from use of Content Hints, but I do
not believe this is proscriptive (there isn't a "SHOULD NOT").

  Why is something more required?

Regards,
Chris

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alicia da
Conceicao
Sent: Tuesday, December 13, 2005 10:56
To: Tony Capel
Subject: Re: SignedAttribute for Mime-Type

> binary in the MIME header. There is no mandatory requirement to
base64 
> encode the mime content. In fact, it is recommended not to
(except 
> under certain circumstances) = since it leads to unnecessary
message 
> expansion.

Dear Tony:

Because of this, I did not impliment any type of data formating
for my CMS structures.  In fact, I specifically avoided it for
several reasons, including:

2) identical core data can be encapsulated differently or have
	sightly different headers, which would give them
different
	hashes; this would make pairing up signatures with their
	detached data nearly impossible

3) time stamp tokens, which are also detached signatures, also
only
	hash the core data itself in the TSTInfo, and do not use
any
	type of encapsulation or headers, since all time stamp
	tokens are used for detached data

Currently, I am using CMS for lots of thing completely unrelated
to S/MIME or e-mail.  In practice, more than 10% of the
signatures generated using my CMS software are for detached data.
It just seems easier to simply specify a MIME type for the core
data as an attribute that would work for both attached and
detached signatures.

Alicia.

=================================================================
====

4 Data Content Type

   The following object identifier identifies the data content
type:

   The data content type is intended to refer to arbitrary octet
   strings, such as ASCII text files; the interpretation is left
to the
   application.  Such strings need not have any internal
structure
   (although they could have their own ASN.1 definition or other
   structure).

   S/MIME uses id-data to identify MIME encoded content.  The use
of
   this content identifier is specified in RFC 2311 for S/MIME v2
   [OLDMSG] and RFC 2633 for S/MIME v3 [MSG].

   The data content type is generally encapsulated in the
signed-data,
   enveloped-data, digested-data, encrypted-data, or
authenticated-data
   content type.

   This section contains a word of warning to implementers that
wish to
   support both the CMS and PKCS #7 [PKCS#7] SignedData content
types.
   Both the CMS and PKCS #7 identify the type of the encapsulated
   content with an object identifier, but the ASN.1 type of the
content
   itself is variable in PKCS #7 SignedData content type.

   The CMS definition is much easier to use in most applications,
and it
   is compatible with both S/MIME v2 and S/MIME v3.  S/MIME
signed
   messages using the CMS and PKCS #7 are compatible because
identical
   signed message formats are specified in RFC 2311 for S/MIME v2
   [OLDMSG] and RFC 2633 for S/MIME v3 [MSG].  S/MIME v2
encapsulates
   the MIME content in a Data type (that is, an OCTET STRING)
carried in
   the SignedData contentInfo content ANY field, and S/MIME v3
carries
   the MIME content in the SignedData encapContentInfo eContent
OCTET
   STRING.  Therefore, in both S/MIME v2 and S/MIME v3, the MIME
content
   is placed in an OCTET STRING and the message digest is
computed over
   the identical portions of the content.  That is, the message
digest
   is computed over the octets comprising the value of the OCTET
STRING,
   neither the tag nor length octets are included.

   There are incompatibilities between the CMS and PKCS #7
signedData
   types when the encapsulated content is not formatted using the
Data
   type.  For example, when an RFC 2634 [ESS] signed receipt is
   encapsulated in the CMS signedData type, then the Receipt
SEQUENCE is
   encoded in the signedData encapContentInfo eContent OCTET
STRING and
   the message digest is computed using the entire Receipt
SEQUENCE
   encoding (including tag, length and value octets).  However,
if an
   RFC 2634 signed receipt is encapsulated in the PKCS #7
signedData
   type, then the Receipt SEQUENCE is DER encoded [X.509-88] in
the
   SignedData contentInfo content ANY field (a SEQUENCE, not an
OCTET
   STRING).  Therefore, the message digest is computed using only
the
   value octets of the Receipt SEQUENCE encoding.

   The following strategy can be used to achieve backward
compatibility
   with PKCS #7 when processing SignedData content types.  If the
   implementation is unable to ASN.1 decode the signedData type
using
   the CMS signedData encapContentInfo eContent OCTET STRING
syntax,
   then the implementation MAY attempt to decode the signedData
type
   using the PKCS #7 SignedData contentInfo content ANY syntax
and
   compute the message digest accordingly.

   The following strategy can be used to achieve backward
compatibility
   with PKCS #7 when creating a SignedData content type in which
the
   encapsulated content is not formatted using the Data type.
   Implementations MAY examine the value of the eContentType, and
then
   adjust the expected DER encoding of eContent based on the
object
   identifier value.  For example, to support Microsoft
AuthentiCode,
   the following information MAY be included:

      eContentType Object Identifier is set to { 1 3 6 1 4 1 311
2 1 4 }

      eContent contains DER encoded AuthentiCode signing
information

---

From: Alicia da Conceicao <[email-masked]>
Date: Tue, 13 Dec 2005 16:07:02 -0500 (EST)

>   Why is something more required?

Hi Chris:

This is a excellent suggestion, that would meet my needs.  :-)
My only concern is that the UTF8String contentDescription appears
to somewhat vague.

Should I prepend the MIME type for the content with a text qualifier
in the contentDescription?

As an example, consider a CMS SignedData structure for a digital
signature of an MS word document.

Should I specify "Content-Type: application/msword" or just
"application/msword" in the contentDescription of the ContentHints
attribute?

Also on a side note, digital signatures can be nested.  For CMS
SignedData objects, there is no office media type:

	http://www.iana.org/assignments/media-types/index.html

The closest match is for PKCS7 signatures:

	application/pkcs7-signature

However, its usage as specified in RFC-2311 can deviate from generic
CMS.  Prehaps we need to have an "application/cms-signature" media
type.

Thanks again Chris for your excellent suggestion!  :-)
Alicia.

---

From: "Tony Capel" <[email-masked]>
Date: Tue, 13 Dec 2005 16:53:53 -0500

Alicia:

I was just responding to:
 
"The data being signed must remain in binary form,
it is too large to do any type of text encoding
such as base64, in order to just specify S/MIME
related MIME-Type text headers."
 
Of course, there is no need to text encode the
binary data to use S/MIME, so the size of the
binary data need not be a factor.  The overhead
can be only the header and boundary octets (which
happen to be 7-bit).
 
We are also using CMS for a "non-e-mail" application 
but chose to use MIME encoding (with binary transfer 
encoding) since it provided a number of advantages, 
including the ability to bind the content type to 
the signature (as per your second post I think...).  
 
I understand that you have an application where you 
do not wish to MIME encode the content and would 
prefer (some) functions available from MIME to be 
available directly with CMS.
 
In our specific case we avoid detached signatures -
this was not desirable - so the issues you raise 
in your follow-up posting we did not need to consider.
 
We just mandated that the data formats at the input 
and output of the CMS processes be MIME encoded 
(but allowing binary transport).  This way we could 
use the MIME headers to identify transfer encoding, 
content type, private header extensions, etc. at the 
input and output of the secure channel, knowing that 
the headers are not changed in transit (this allows 
the transfer of additional secure "out of band" 
signalling between the applications & use the MIME 
standard for that signalling).  So in our case 
the trusted timestamp would be over the MIME encoded 
data including headers.  The MIME overhead was 
considered to be small compared with the benefits of
sticking with a fairly widely used MIME standard.
 
But then again, one size does not fit all 
(and I agree that having MIME text mixed with CMS ASN.1 
is a bit odd and perhaps peculiar to e-mail applications.
I also agree that CMS Section 4 could be clearer, but 
there are a lot of e-mail apps which assume MIME ...),

Cheers,

Tony

-----Original Message-----
From: Alicia da Conceicao [mailto:[email-masked]] 
Sent: December 13, 2005 10:56 AM
To: Tony Capel
Subject: Re: SignedAttribute for Mime-Type

> binary in the MIME header. There is no mandatory requirement to base64 
> encode the mime content. In fact, it is recommended not to (except 
> under certain circumstances) = since it leads to unnecessary message 
> expansion.

Dear Tony:

Thank you for your response.  CMS requires all data content types to be
arbitrary octet strings, with the interpretation is left to the application.
There is no requirement to use any type of textual S/MIME headers in the data.
I attached the relevant sections from the CMS rfc below.

Because of this, I did not impliment any type of data formating for my CMS
structures.  In fact, I specifically avoided it for several reasons, including:

Currently, I am using CMS for lots of thing completely unrelated to S/MIME or
e-mail.  In practice, more than 10% of the signatures generated using my CMS
software are for detached data.  It just seems easier to simply specify a MIME
type for the core data as an attribute that would work for both attached and
detached signatures.

Alicia.

4 Data Content Type

---

From: Alicia da Conceicao <[email-masked]>
Date: Tue, 13 Dec 2005 18:12:13 -0500 (EST)

Hi Tony:

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:

	Content-Type: multipart/mixed
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.

Alicia.