- From: Mike West <mkwst@google.com>
- Date: Sat, 17 Jan 2015 13:14:13 +0100
- To: Brad Hill <hillbrad@gmail.com>
- Cc: Joel Weinberger <jww@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=eThyngoEgEkYrZZ_VkhDRRAzJBBaMrS2gtZi58=p8Hnw@mail.gmail.com>
We should certainly match SRI's behavior here, both for base64url and for "sha-256" vs "sha256": WDYT of https://github.com/w3c/webappsec/commit/7b3b425ae340734a088323ff2ffb7f575d7e3163 ? -mike -- Mike West <mkwst@google.com>, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Sat, Jan 17, 2015 at 12:13 AM, Brad Hill <hillbrad@gmail.com> wrote: > Sounds good to me. There is no ambiguity in the decoded set of bits, so I > don't think there's much risk in doing so as long as UA implementations are > uniform in accepting both encodings. > > On Fri Jan 16 2015 at 3:08:56 PM Joel Weinberger <jww@chromium.org> wrote: > >> In CSP Source List Syntax >> <https://w3c.github.io/webappsec/specs/content-security-policy/#base64_value> definition, >> base64-value is listed as purely a base64 value. This is inconsistent with >> the Subresource Integrity draft, which proposes to use base64url >> <http://www.w3.org/TR/SRI/#integrity-metadata-1>. Furthermore, in >> practice, Chrome accepts both base64 and base64url for Subresource >> Integrity *and* CSP. I propose that we standardize this and accept >> either base64 *or* base64url in CSP. I've opened issue 147 >> <https://github.com/w3c/webappsec/issues/147> on GitHub to propose this. >> --Joel >> >
Received on Saturday, 17 January 2015 12:15:00 UTC