Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard

[Jonathan A Rees <[e-mail]>]

On Fri, Jun 8, 2012 at 9:45 PM, Stephen Farrell
<[e-mail]> 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.)