- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 11 Dec 2013 13:41:51 +0000
- To: Mike West <mkwst@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Neil Matatall <neilm@twitter.com>, Garrett Robinson <grobinson@mozilla.com>, Joel Weinberger <jww@google.com>, Adam Barth <w3c@adambarth.com>, Brad Hill <bhill@paypal-inc.com>, Dan Veditz <dveditz@mozilla.com>, Mark Nottingham <mnot@mnot.net>
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:42:19 UTC