- From: Francois Marier <francois@mozilla.com>
- Date: Sat, 31 Jan 2015 17:09:54 +1300
- To: WebAppSec WG <public-webappsec@w3.org>
On 31/01/15 16:03, Martin Thomson wrote: > None of your example show this, but hash-source has single quotes > around it: https://w3c.github.io/webappsec/specs/content-security-policy/#hash_source Indeed, thanks for pointing it out. I was implicitly ignoring the quotes, but it should be stated explicitly. I didn't really see a need (in SRI) for extra quotes given that a hash-source doesn't contain any whitespace. > Without the quotes, a hash-source for a new hash algorithm is going to > marginally harder to distinguish from an option, so I think that's > good. Under that proposal, an option would look like "option:value" whereas a new hash would look like "sha3000-value". So yes, it's a one-character difference. On the other hand, a large base64 hash looks quite different from what we're likely to use as values for the options. > I note that all of your examples use base64. The ni URL uses > base64url. I have a small (small) preference for base64url without > padding. Is there any reason to pick one over the other? I used base64 (not base64url) for two reasons: 1. both gecko and blink use base64 internally 2. CSP Level 2 uses base64 Note that #2 has just changed [1], but one of the reasons why it changed is to match the SRI spec [2] :) We should probably ensure that CSP and SRI are using the same encoding, whatever that ends up being. Francois [1] https://github.com/w3c/webappsec/pull/154 [2] https://github.com/w3c/webappsec/pull/156#issuecomment-72209356
Received on Saturday, 31 January 2015 04:10:26 UTC