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