Re: eContentType for detached signatures

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 <[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