Re: eContentType for detached signatures

On May 2, 2014, at 7:22 AM, Russ Housley <[email protected]> wrote:

> I do not agree.  When working on RFC 5485, the idea was to use a canonicalization that was already well defined and widely implemented.  

NVT-ASCII is well defined and is not widely implemented, at least not implemented correctly.

> That is why the FTP wire format for plain text was selected.

Calling NVT-ASCII the "FTP wire format" is an overstatement. Many or most implementations only do the CRLF transposition, not the whitespace stripping.

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

This means that anyone who wants to create a detached signature for a type of data that is not currently in the registry needs to write a specification and apply for one. It seems strange to believe that no one in the past five years has created a detached signature for, say, an MP3, a stand-alone HTML file or a JSON file.

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

Are you saying there will be significant negative operational impact of replacing those signatures with new ones? Given the "some" in that last sentence, I'm not sure I can imagine the problems.

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

That was the least important proposal of the bunch for the work at hand.

--Paul Hoffman
_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime