Alicia (sorry for the delay in replying):
I think the contents hints might only need to specify MIME, or
[ASN.1+content encoding rules], .... The hints would just
identify the next protocol sublayer to process the content
(service access point).
So the hints candidates might be:
1. MIME
2. ASN.1 + BER/DER
3. ASN.1 + PER (?)
+ future and private use OIDs.
Both MIME and ASN.1 BER have the ability to identify content so I expect that
"future and private use" would only be for applications which are NOT using
these encodings (since they provide their own extension mechanisms). This would
minimize the impact on CMS (we don't need OIDs matching MIME types for example).
On your second point about the clarity of the current text, I agree some added
words might be useful to cover the case where no content hints are provided (and
no a priori agreement exists). The use of MIME within "e-mail applications"
might be considered as implying an a priori agreement - so I am not convinced
there is a serious problem. It is tempting to point out that long and
indefinite BER encodings of ASN.1 will have the msb of the first octet set while
"common" 7-bit MIME will not. However I am not sure that the BER short form is
never used, or that we can guarantee all 7-bit MIME has the msb clear. Maybe
others would comment whether such text would help (and not break existing
implementations).
Russ has just reminded us of another issue raised by Bellovin and Rescorla
(multi-level signature) potentially impacting CMS, so perhaps this should be
discussed some more if that is the direction of the WG.
Tony
-----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: December 13, 2005 6:12 PM
To: Tony Capel
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: SignedAttribute for Mime-Type
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.