Re: CfC: Transition CSP2 to CR.

I agree pretty completely with Brian. If SRI moves away from the `ni:`
format, and thereby does away with the requirement to support base64uri,
then let's remove it from both specs. We only added it to CSP to reduce
impedance between the two specs; if there's no mismatch, then I don't think
there's any need to complicate the message we send to users.

Ditto `sha256` vs `sha-256`.

-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 Mon, Feb 9, 2015 at 5:15 AM, Brian Smith <brian@briansmith.org> wrote:

> [+rsleevi]
>
> Francois Marier <francois@mozilla.com> wrote:
> > On 06/02/15 21:25, Mike West wrote:
> >> Any other issues folks have on their mind for CSP2?
> >
> > CSP2 recently added support for Base64url hashes citing parity with SRI
> > as one of the reasons [1] for this change.
> >
> > Given that the final SRI spec may be moving away from URIs for encoding
> > the hashes [2], and that CSP hashes are not URIs either, I was
> > wondering: is there a reason to use a URL-safe encoding of Base64 as
> > opposed to just regular base64?
> >
> > It's fairly trivial to support both in user agents, but it adds a small
> > amount of complexity to both specs.
> >
> > I don't have a strong opinion on this, but I wanted to note that this
> > decision will have an impact on what we do in the SRI spec too.
>
> I think it is important for SRI, CSP, HPKP, and other HTTP security
> mechanisms to use similar rules and syntax for things like this,
> whenever practical, because consistency should result in better
> usability for the (security) engineers trying to deploy these
> features.
>
> Also, I think when there are two possible ways to write something,
> specifications should state a preference for one over the other, to
> encourage tutorials and examples that are consistent with each other
> and thus easier to understand.
>
> In particular, CSP and SRI should specify a preference for base64
> encoding over base64url encoding, and for identifying hashes without
> the dash ("sha256" instead of "sha-256") since that's what HPKP
> requires [1][2]. And, either CSP and SRI should remove or deprecate
> the non-preferred forms, or HPKP should add support for them.
>
> I'm guessing it is either too late for HPKP to be changed and/or it is
> unlikely that the IETF would be willing to change HPKP to add support
> for base64url or to support the with-dash syntaxes. So, I slightly
> prefer dropping support for base64url encoding and for the with-dash
> form of digest names.
>
> Cheers,
> Brian
>
> [1]
> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.1.1
>
>