On Fri, Jun 8, 2012 at 9:45 PM, Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> 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.)