W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

[integrity] Different ways to associate integrity information

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 24 Oct 2014 14:47:55 +1100
Message-Id: <C4D9F238-C838-4642-967E-28A2AAD4AC3C@mnot.net>
To: WebAppSec WG <public-webappsec@w3.org>
Has there been any discussion of how the integrity information is associated with a resource?

I think using the integrity attribute on the link makes sense for the most current use case -- assuring that off-site content (e.g., on a CDN) is what you think it's going to be. That's because in these cases, the URL is most likely to be a version-specific one (<e.g., https://cdn.com/foolib.1.2.3.js>), so if the author wants to update the library version used, they'll need to update the link, and the integrity information is right next to it.

However, in the cache reuse case -- which seems to be getting *some* traction (or at least consideration) -- next to the link is about the worst place the integrity information can go; if the author updates the library, they'll need to update each and every instance of a link to it, which can be quite onerous. 

In that use case, it makes more sense to put integrity information into HTTP headers or even a separate resource, so that it can more easily be updated (e.g., by a separate process, or automatically by the server at response time).

So, I'm wondering if the WG would consider allowing integrity information to be carried in HTTP response headers (e.g., Link), at least for the cache reuse case.

Cheers,

--
Mark Nottingham   https://www.mnot.net/
Received on Friday, 24 October 2014 03:48:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC