Re: Hashes.

Note that what I've added here is distinct from the subresource integrity
use case. I very much want to push validation of external resources
forward, but this isn't that.

I have a half-started spec for that bit which I promised a few folks I'd
have in a sharable state sometime in November. Oops. :(

On Dec 11, 2013 2:41 PM, "Anne van Kesteren" <> wrote:

> On Wed, Dec 11, 2013 at 11:04 AM, Mike West <> wrote:
> > 1. I'm deferring to the HTML spec for the definition of the script
> block's
> > source, which I think gives us good chances of both understanding how the
> > script block is parsed and understood, and interoperating on that
> > understanding. Adam, your input would be particularly valued here: is
> that
> > definition enough, or do we need to more explicitly talk about encodings
> and
> > canonicalization?
> If we are adding hashes (as a way to allow http within https, to allow
> for cache-by-hash lookup) they should be about the resource's entity
> body. We want to use this for more than scripts.
> > 3. I'm running with Garrett's suggestion that we support only SHA-2
> > algorithms. I think there's value in supporting SHA-1 (number of bits on
> the
> > wire, if nothing else), and I'd like to add it in. Moreover, there might
> be
> > value in writing the spec such that future algorithms can be supported if
> > browser vendors choose. I'm not sure we need to be explicit about the
> > supported algorithms (other than to specify something like SHA-256 as
> > mandatory to support, to ensure we have a common baseline). Opinions
> > welcome. :)
> I think it would be much better if this was nailed down. And whenever
> we decided something new was warranted we would update the
> specification.
> Adding Mark, as he had an interest in this.
> --

Received on Wednesday, 11 December 2013 13:56:05 UTC