W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2013

Re: Hashes.

From: Mike West <mkwst@google.com>
Date: Wed, 11 Dec 2013 14:55:37 +0100
Message-ID: <CAKXHy=dUhxxJY4d95TkgpGc3+djst0NN22gdOgK5pnThsJ1FkA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Mark Nottingham <mnot@mnot.net>, Dan Veditz <dveditz@mozilla.com>, Brad Hill <bhill@paypal-inc.com>, Joel Weinberger <jww@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Adam Barth <w3c@adambarth.com>, Garrett Robinson <grobinson@mozilla.com>, Neil Matatall <neilm@twitter.com>
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" <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/
Received on Wednesday, 11 December 2013 13:56:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:35 UTC