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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Alicia da
Conceicao
Sent: Tuesday, December 13, 2005 10:56
To: Tony Capel
Subject: Re: SignedAttribute for Mime-Type
(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