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.1.9.16.2.4 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
http://www.nbusr.sk/en/electronic-signature/signature-policies.1.html
http://ep.nbusr.sk/kca/tsl/tsl.xml.p7s
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:
DataReferences:
{
"hash": {
"OID": "2.16.840.1.101.3.4.2.1",
"parameters": "",
"name": "SHA256"
},
"fields": [
{
"data": {
"url": "http://www.archive.eu/docs/?typ=123";,
"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": "http://www.archive.eu/docs/?typ=432";,
"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
Cc: IETF SMIME
Subject: Re: [smime] eContentType for detached signatures
On May 1, 2014, at 11:37 AM, Russ Housley <housley(_at_)vigilsec(_dot_)com>
wrote:
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
signature.
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
forward.
- Obsolete RFC 5485 with a new document of similar structure but more careful
wording.
- 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
signatures.
- 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime