W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

Re: [SRI] Updates to the spec and outstanding issues

From: Nottingham, Mark <mnotting@akamai.com>
Date: Fri, 20 Mar 2015 04:22:55 +0000
To: Devdatta Akhawe <dev.akhawe@gmail.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <97888B37-9E2A-454E-B1D8-07C4F90AD34D@akamai.com>

> On 18 Mar 2015, at 3:30 pm, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
>> * 3.2.2 Priority says "That is, getPrioritizedHashFunction(a, b) MUST return..."  Does this imply that a function called that is required to be implemented? If so, where is it defined?
> I think we are trying to say that "UAs should have such a function,
> even if it is just 'return a;'"". We definitely don't want to mandate
> a priority list since UAs should have the flexibility to evolve this
> as we learn more about hash functions. How do you suggest spec'ing
> this?

I was wondering if there was WebIDL for the function, etc. You might want to change to something like:

“That is, if a UA implemented a function like getPrioritizedHashFunction(a, b), it would return…”

Note the downgrade from MUST to prose, since this isn’t a testable conformance requirement.

>> * Generally, the spec seems somewhat RFC2119-happy; just because it's natural english to say "must" or "should" in a sentence doesn't mean it's a conformance requirement.
> While I will do a pass closer to LC to spot such issues, if you have
> thoughts on lines that could be changed, feel free to point them out
> here or on Github.


>> * The specification of how headers affect eligibility in section 3.2.2 needs some work; right now it mixes in request and response headers indiscriminately (see above re: "resource").  Also, how does HTTP authentication affect integrity?
> We are slowly leaning towards (in v1) insisting on CORS. So, will that assuage your concerns?

My concern was more about how it’s specified, in terms of HTTP. If this section is going to change, I’ll wait for that and re-review.

>> * Integrity data will be easier to add in some server-side scenarios if it's possible to convey it in HTTP headers on the response, rather than in the HTML (or CSS, or JS). For example:
>> HTTP/1.1 200 OK
>> Content-Type: text/html
>> Link: <...>; rel="stylesheet"; type="text/css"; integrity="..."
>> ...
> I don't recall, but this is definitely vNext material.

Why “definitely”? Has it already been discussed and decided?


Mark Nottingham    mnot@akamai.com    https://www.mnot.net/

Received on Friday, 20 March 2015 04:24:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:47 UTC