Re: CfC: Subresource Integrity (SRI) to Last Call?

Hi Austin

The simple truth is that there are already implementations that use the new
style. I am not sure that the concerns you raise are actually going to be a
problem, but I agree with you that they could be. This is exactly why the
spec was modified to explicitly allow the possibility of us changing syntax
and introducing more formats (the spec mandates UAs to ignore syntax they
don't know about). You also pointed out some concerns and made a PR that
was pulled in IIRC.

Do you have suggestions of what we could do beyond that? Changing
implementations and spec to use ni:// at this point is extremely unlikely.

cheers
Dev

On 21 April 2015 at 12:47, Austin William Wright <aaa@bzfx.net> wrote:

> I've sort of skipped ahead to the 'call for implementations' part (but of
> course, don't let this stop breaking changes) with a Drupal module [1].
>
> Recent changes to the document seems to have been highly motivated by user
> agent concerns. I'm guessing there's been a number of implementation
> concerns where it was just easier to remove certain functionality
> altogether?
>
> First, I'm concerned that there's now no way to fix the media type of the
> response, since it's the case that two identical information resources can
> have completely different interpretations based on their media type. I
> would like to see the possibility of this attack noted in Security
> Considerations, and if this is addressable with e.g. CSP, a note on how to
> do that.
>
> Second, as described in my earlier email, I would still like to push to
> adopt an NI-compatible hash identifier. The "<alg>-<hash>" syntax seems
> just as arbitrary as "ni:///<alg>;<hash>", except the latter allows forward
> compatibility with ni: URIs. SRI has a great number of implications beyond
> those of CSP, and so I'm interested in the draft not painting itself into a
> corner. Specifically, SRI walks and quacks like a link attribute (like
> "rel", "title", "type", etc), and I see it being used in more general cases
> in the future, including for purely server-side uses.
>
> Tangential to the ni: URI issue are things like 'hard-coding' hash
> algorithms (instead of referring to e.g. the IANA registry), and use of a
> dash "-" to split the algorithm from the hash, instead of a more common
> separator character like a semicolon. I don't think these negatives are
> worth it just to share syntax with CSP, the use-cases are, in reality,
> largely orthogonal.
>
> Cheers,
>
> Austin.
>
> [1] <https://github.com/Acubed/drupal-sri>
> Actually I worked on this a while ago. It's sort of out of date as of now.
>
>
>
> On Mon, Apr 20, 2015 at 11:55 PM, Frederik Braun <fbraun@mozilla.com>
> wrote:
>
>> The remaining open issues[1] on GitHub are mostly editorial nits. The
>> technical parts should be well in place to advance to Last Call.
>>
>> I am aware of no fundamental controversies but would really like to get
>> some wider attention on the spec.
>>
>> The current editor's draft is at
>> <http://w3c.github.io/webappsec/specs/subresourceintegrity/>.
>>
>>
>> The CfC will end in a week, that is April 28th, 2015.
>>
>>
>>
>> [1]
>> <
>> https://github.com/w3c/webappsec/issues?q=is%3Aopen+is%3Aissue+label%3ASRI+milestone%3ASRI-v1-LC
>> >
>> and
>> <
>> https://github.com/w3c/webappsec/issues?q=is%3Aopen+is%3Aissue+label%3ASRI+no%3Amilestone
>> >
>>
>>
>