[Top] [All Lists]

Re: [smime] eContentType for detached signatures

2014-05-02 09:52:47
On May 2, 2014, at 7:22 AM, Russ Housley <housley(_at_)vigilsec(_dot_)com> 

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