On Fri, Jun 8, 2012 at 9:45 PM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: > > Hi Sam, > > On 06/09/2012 01:43 AM, Sam Hartman wrote: >> Add me as a +1 for the idea that content-type is important for this. >> I tend to agree with the arguments given so far. Namely, for some >> important use cases you're going to want to know the content type and >> guessing is really a bad idea. > > Thusly counted:-) > >> >> That said, there are security considerations associated with specifying >> a content type too. I'm particularly imagining a situation where some >> sort of deep inspection security appliance uses a different procedure >> for deciding what kind of foo it is than the ultimate application. One >> guesses based on byte stream another looks at a content type. This is >> well known; it's not new; it's probably even so documented that any >> reasonably current set of MIME security considerations already includes >> a reference. > > My only real concern with adding this is the issue of complexity > related to c14n of input to the hash function. While CMS does (I > think) define that well, imposing that burden on anyone that might > want to write code that validates name-data integrity is an issue. > Anyway, if we want to add it we'll look that over and figure how > it might best be done. OK, I agree that's an issue. My feeling is that it's not much of a burden, and to the extent it is a burden it's important to take on. I'm not sure but wouldn't the burden just be: If (1) the client is sensitive to media type, and (2) it gets a media type from the server, and (3) ct= is provided, and (4) they don't match, you either ignore the type from the server, or treat it as spoofing. Otherwise - you just do what you would have done, had ct= not been mentioned in the spec. Clients or protocols for which either (1) or (2) doesn't apply are unaffected; if (1-2-3) apply then the situation is important. (Come to think of it the same consideration applies to data: ... of course it's not common to use a data: URI as the request URI in an HTTP request.)