[Top] [All Lists]

Re: [smime] eContentType for detached signatures

2014-05-02 09:23:34

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.


On May 1, 2014, at 5:46 PM, Paul Hoffman wrote:

On May 1, 2014, at 11:37 AM, Russ Housley <housley(_at_)vigilsec(_dot_)com> 

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 

- Obsolete RFC 5485 with a new document of similar structure but more careful 

- 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 

- 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