(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