ietf-smime
[Top] [All Lists]

Re: SignedAttribute for Mime-Type

2005-12-13 10:35:51

(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


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