[Top] [All Lists]

Re: [smime] eContentType for detached signatures

2014-04-30 18:26:59
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

<Prev in Thread] Current Thread [Next in Thread>