W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2014

Re: Couple comments on Subresource Integrity

From: Brad Hill <hillbrad@gmail.com>
Date: Mon, 24 Mar 2014 21:27:58 -0700
Message-ID: <CAEeYn8gcNGO-i9hziV2yZexWmc6mi-n3a_ujGFT7o7zj2efCcA@mail.gmail.com>
To: Trevor Perrin <trevp@trevp.net>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Because it's a standard, so we don't re-invent the wheel every time we or
someone else does something like this.   And maybe it's 20 pages because it
went through a cycle of peer review at the IETF that addressed hopefully
most of the issues and edge cases that we would probably painfully
recapitulate, one at a time, over the next year if we did just try another
one-off.  Seems like the cost of a few extra characters is small in
comparison.


On Mon, Mar 24, 2014 at 8:03 PM, Trevor Perrin <trevp@trevp.net> wrote:

> On Mon, Mar 24, 2014 at 7:11 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
> > Hi Trevor
> >
> >> 1) Why does the content-type need to be specified in the link?  Why
> >> not just include it as input to the hash?
> >
> > I believe this is because the existing RFC already uses the syntax.
> > See http://tools.ietf.org/html/rfc6920#section-3.1
>
>
> Hi Devdatta,
>
> What does the RFC 6920 format give you compared to a simple
> algo-specific attribute like sha256="base64...", and then hashing the
> content-type followed by a separator char (";") prior to the data?
>
> The 6920 format adds verbosity, parsing, and having to read a 20-page
> (?!) doc.  What's the benefit?
>
>
> Trevor
>
>
Received on Tuesday, 25 March 2014 04:28:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC