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

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
> >
>
>