- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Sat, 7 Feb 2015 23:00:53 -0800
- To: Francois Marier <francois@mozilla.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Circling back to this; what do ya'll think should we go with here? I still believe we should fail open and then go with the SSL style deprecation Brad suggested. If a browser knows that a hash is insecure, it can start showing warning before failing closed. We don't need to spec this. If a browser doesn't know of a hash, it should just ignore it (maybe with a warning). This makes sense to me in that the presence of a known bad hash is a signal for a UA to make some security decisions; but not knowing an algorithm might just be that the UA is old enough and doesn't know any good, safe algorithms. cheers Dev On 3 January 2015 at 12:46, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: >> 1. <script integrity="ni:///sha-512;foo"> for a modern browser that no >> longer considers that hash algorithm secure >> >> 2. <script integrity="ni:///sha-1024;foo"> for an older browser that >> doesn't know about this new hash algorithm >> >> I think you're suggesting we fail open (for a time anyways) in the first >> case by keeping a list of known-but-no-longer-trusted hash algorithms. I >> can draft a pull request for this. > > Do we really need to spec the first case? I think we should leave it > to UAs to decide what is best for their users. > > cheers > Dev
Received on Sunday, 8 February 2015 07:01:40 UTC