W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [SRI] format of the integrity attribute

From: Francois Marier <francois@mozilla.com>
Date: Sat, 31 Jan 2015 17:09:54 +1300
Message-ID: <54CC5592.1050003@mozilla.com>
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

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.


[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

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