[Top] [All Lists]

Re: [smime] eContentType for detached signatures

2014-05-01 13:38:16

I still think that we did a reasonable thing in RFC 5485.

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.


On Apr 30, 2014, at 7:25 PM, Paul Hoffman wrote:

We agree that having a id-ct-mime would be a good thing. We also seem to 
agree that id-ct-asciiTextWithCRLF signals that the content must be be 
processed with the exact canonicalization specified in RFC 5485 before 
signing and validation. I was wrong when I said that I didn't see the need 
for the type for the content type you are focused on; I was actually looking 
at the other two types that were defined in RFC 5485, id-ct-xml and 
id-ct-pdf, which do not use the canonicalization rules given in the RFC. It 
was from there that I worry that this indicates that all types, not only 
those that need canonicalization, need to be defined, given that we have no 
definition for any.

This thread was prompted by Russ asking that, when Internet Drafts and RFCs 
no longer are expected to be all-ASCII, do we need another CMS content type. 
To me, this means making up a new canonicalization form for these, but we 
will also need to make one up for all the for other types that might be 
published. Further, it pointed out to me that the canonicalization that is 
defined in RFC 5485 is already fragile. It doesn't apply to two of the types 
defined in that RFC, and it makes a false assumption that all inputs are 
really ASCII (sometimes, non-ASCII characters slip through).

So, I still question whether or not RFC 5485 did the right thing in defining 
id-ct-xml and id-ct-pdf, and particularly in not defining something that 
could be called id-ct-unknown.

--Paul Hoffman

smime mailing list