Re: Couple comments on Subresource Integrity

Bjoern wrote:
> Tight coupling has a number of downsides; an example is that implemen-
> tations can detect the presence of integrity information even when the
> document uses an unrecognised algorithm.

Hi Bjoern,

I didn't see where the spec handles an unrecognized hash algo
different from absent integrity info?


Devdatta wrote:
>> The 6920 format adds verbosity, parsing, and having to read a 20-page
>> (?!) doc.  What's the benefit?
>
> I am curious: are these the only concerns you have with using the RFC 6920?

I also think you're assuming 6920 solves things it doesn't.

So you probably need to think more about things like registering algo
names, hash truncation, hash agility, content negotiation,
canonicalization, etc.


Devdatta wrote:
> One benefit of having content type as separate meta-data is the
> browser can send that and only that in the "accept" header.

Thanks for explaining that.

I'll have to think more about it.  Do you need the HTML to specify
other content negotiation headers, like Accept-Language,
Accept-Charset, Accept-Encoding, etc?


On Tue, Mar 25, 2014 at 9:38 AM, Brad Hill <hillbrad@gmail.com> wrote:
> Regarding explicit specification of content-type, consider if we eventually
> decided to use the hash identifiers for retrieving things from some type of
> content-addressable-storage.  The browser might have the correct bits laying
> around, but they may have been delivered over a non-HTTP mechanism or the
> original headers may not have been preserved.
>
> Using a standard format also is how we start to build an ecosystem around
> these ideas.  In the future you might be able to use a local CDN that allows
> ni:// urls to be used like magnet links, etc.

Or you could do all this w/base64 hashes.  I'm not aware of anyone
else using 6920, so I don't think there's an "ecosystem" to speak of.


> I'd rather reference a 20 page spec that's done and add a new algorithm to
> the already-established registry than re-invent 10 or even 5 pages inline
> with this one unless there are good reasons not to use the existing spec.

Your spec already describes how to base64 a hash (3.3.1).  Deleting
the 6920 references would shorten this document, seems to me.

---

Anyways, I think this spec is a great idea and how you base64 the hash
doesn't really matter.  I'd be happy to drop this while bigger issues
are discussed.

But maybe you could keep in mind for the future that it might be
possible to simplify the encoding.


Trevor

Received on Tuesday, 25 March 2014 19:05:31 UTC