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. :(

-mike
On Dec 11, 2013 2:41 PM, "Anne van Kesteren" <annevk@annevk.nl> wrote:

> On Wed, Dec 11, 2013 at 11:04 AM, Mike West <mkwst@google.com> 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.
>
>
> --
> http://annevankesteren.nl/
>