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
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
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.
smime mailing list