Re: eContentType for detached signatures

On May 1, 2014, at 11:37 AM, Russ Housley <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/smime