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

Re: [Integrity] typos with ni URIs

From: Brian Smith <brian@briansmith.org>
Date: Sun, 18 Jan 2015 21:37:01 -0800
Message-ID: <CAFewVt5TDCk16CRE854mqa1VOfknBoMv8k--2VY-3szm4VDZvg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, "Manger, James" <James.H.Manger@team.telstra.com>
Martin Thomson <martin.thomson@gmail.com> wrote:
> I know a lot of base64 libs accept the '+/' and '-_' variants
> interchangeably as well.  Is that something that should be accepted or
> not?

It's probably best for webappsec specs to choose one syntax (either
regular base64 encoding, or base64url encoding), and use it

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

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

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.

Received on Monday, 19 January 2015 05:37:28 UTC

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