Re: [Integrity] typos with ni URIs

On Mon, Jan 19, 2015 at 6:37 AM, Brian Smith <brian@briansmith.org> wrote:

> > For new stuff, I consider Postel's "accept any old trash" maxim as bad
>
> advice; and generally consider it to be fatalistic when it comes to
> > old junk,
>
> I understand how this could be considered an application of Postel's
> rule, which I also don't generally agree with, but...
>

Why is it beneficial for the user agent to reject an encoding that it could
trivially understand? It doesn't feel like we're jumping through hoops to
accept "any old" encoding if we accept either "+" or "/" in an encoded hash.

If we started saying "well, on my keyboard, if I forget to hold shift to
type '+', then I might end up with '=', so let's accept that too", I'd
certainly argue against it, but accepting two well-known variants doesn't
come anywhere near that strawman. :)


> > recogizing the that at some point correctness has to yield
> > to interoperability.  Is ni:// that decrepit already?
>
> I think it might be the case that the specification of ni:/// URLs is
> unnecessarily strict in saying that the digest must be encoded without
> the "=" padding characters. Note that this is a difference in design
> styles between IETF and WHATWG/W3C.
>

Also, note that both Chrome and Firefox are already violating the "must be
base64url encoded" requirement by accepting base64 encodings.


> Personally, I think that SRI shouldn't use ni:/// URLs at all, because
> the ni:/// syntax is noisy and problematic (e.g. the use of ";" to
> delimit parameters) when used in webappsec specs like CSP.
> Consequently, perhaps the use of ni:/// URLs should be replaced with
> something better.
>

We wanted something that reasonably contained three components of the
integrity metadata: the hash function, the digest, and a content type.
Given that RFC6920 a) existed, and b) encoded all these components, it
seemed like a good choice.

That said, given that we're not using any of the standard's more esoteric
features, I don't think the door is closed to a round of bikeshedding. We
don't even have a last call draft out the door yet, and only one website I
know of has implemented support for the feature. *shrug* I don't personally
find the format annoying enough to bikeshed (11 character overhead in the
maximal case: `ni:///` + `;` + `?ct=`), but the parts we're not
intentionally violating are nicely defined for us. :)

--
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.)