Paul:
I do not agree. When working on RFC 5485, the idea was to use a
canonicalization that was already well defined and widely implemented. That is
why the FTP wire format for plain text was selected.
The detached signature should, in my opinion tell the type of the content being
signed. The use of id-data does not convey this information.
Your last point is incorrect. There have been many I-D signatures that are
correct using id-ct-asciiTextWithCRLF. There are software bugs, and they are
being worked, but some of the signatures are valid.
I have no problem with defining id-ct-mime for cases where the content is MIME
encoded. This object identifier would essentially mean, parse the content to
extract the media type.
Russ
On May 1, 2014, at 5:46 PM, Paul Hoffman wrote:
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