[Top] [All Lists]

Re: [smime] eContentType for detached signatures

2014-05-02 05:40:53
Dear all,

When the binary data (included in a file) are not the same as the HASED binary 
data (included in a hashing procedure), because before hashing procedure the 
data are transformed into the canonical form, there must be also defined a new 
OID for a new canonicalMessageDigest because for OBJECT IDENTIFIER 
1.2.840.113549.1.9.4 messageDigest are defined rules where the whole data are 
as input to the hashing procedure.

The solution, when the whole binary data are hashed but the type of the data 
interpretation/processing is important, for the protection of the type of 
signed data is used signed attribute id-aa-contentHint [RFC2634] where 
contentDescription field contains MIME header with MIME Content-Type:

      SEQUENCE {
       OBJECT IDENTIFIER 1.2.840.113549. contentHint
       SET {
        ContentHints SEQUENCE {
         contentDescription UTF8String 
MIME-Version: 1.0
Content-Type: application/vnd.oasis.opendocument.text; name="ATT00122.odt"
Content-Disposition: attachment; filename="ATT00122.odt"
         contentType OBJECT IDENTIFIER 1.2.840.113549.1.7.1 data

It is also used for secure publication of web files with external CMS signature 
e.g. for a trusted list protection 

When some new rules are expected e.g. when id-ct-canonicalizedText will be 
defined then also id-aa-canonicalMessageDigest must be defined and used.

Proposed creation of a new CMS content type id-ct-mime can be more helpful when 
the document(s) will be signed indirectly.

Signed document identified by id-ct-mime will be DER or maybe a JSON encoded 
DataReferences type. When charset is UTF-8 then it is a binary file without 
canonicalization. Only ASCII txt can be processed with canonicalization.

The JSON proposal below, containing ASCII and UTF-8 data, can be also 
transformed as ASN.1:

    "hash": {
        "OID":          "2.16.840.",
        "parameters":   "",
        "name":                 "SHA256"
    "fields": [ 
      "data": {
        "url": "";,
        "name": "invoice",
        "ext": "txt",
        "Content-Type": "text/plain"      
      "canonicalization": {
        "OID":          "1.2.840.113549.1.7.27",
        "name":                 "asciiTextWithCRLF"
      "hash":           "MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=",
      "info":   "invoice 123"
      "data": {
        "url": "";,
        "name": "invoice",
        "ext": "txt",
        "Content-Type": "text/plain; charset=UTF-8"
      "hash":           "JspKEHtF3LyCalml/2mXuG1jLZ2NjdQCo2hkn+49k7o=",
      "info":   "invoice 432"
Peter Rybar
National Security Authority
Information Security and Electronic Signature Department
Budatinska 30, 850 07 Bratislava 57, Slovak Republic
tel.: +421 2 6869 2163
mob.: +421 903 993 708
fax: +421 2 6869 1701
e-mail: peter(_dot_)rybar(_at_)nbusr(_dot_)sk
e-mail: peterryb(_at_)gmail(_dot_)com

-----Original Message-----
From: smime [mailto:smime-bounces(_at_)ietf(_dot_)org] On Behalf Of Paul Hoffman
Sent: Thursday, May 01, 2014 11:46 PM
To: Russ Housley
Subject: Re: [smime] eContentType for detached signatures

On May 1, 2014, at 11:37 AM, Russ Housley <housley(_at_)vigilsec(_dot_)com> 

I still think that we did a reasonable thing in RFC 5485.

In retrospect, the general idea of "here's a marker for what needs to be 
canonicalized for signing (but not storage) and validating" is probably a good 
one. The implementation on RFC 5485 is confusing and possibly over-broad.

When I was looking at draft-flanagan-nonascii-01, it jumped out to me that 
id-ct-asciiTextWithCRLF would not be appropriate for such documents.  I 
suggested that Heather add an appendix to assign an object identifier for the 
UTF-8 documents that are described here.  That is a reasonable and consistent 
way forward.  There is no place to carry a media type in the detached 

I think id-ct-mime is appropriate for a content that is MIME encoded.  That 
is, the media type is carried in the content.

Jim and I discussed this a bit offline and came up with a reasonable way 

- Obsolete RFC 5485 with a new document of similar structure but more careful 

- Create a new CMS content type id-ct-canonicalizedText that is defined to 
solve the problems of line-ending changes that happen in FTP and in some 
browsers when saving files to disk as text *and that is all*. It would cover 
any text encoded in UTF-8. Do not include stripping of white space before line 
ends; if you do, fully define what characters are "white space" Make it very 
clear that this canonicalization is only for the signing and validation steps, 
*not* for storage on disk or conversion between attached and detached 

- Create a new CMS content type id-ct-mime to assist processors that need to 
know the inner content type of non-text items.

- Discuss that non-text content should be marked with id-data.

- Deprecate all the id-ct values in RFC 5485. This will have nearly zero 
operational impact because the signatures are not long-term (and in fact are 
not being created today due to software bugs).

--Paul Hoffman
smime mailing list

smime mailing list