- From: Brian Smith <brian@briansmith.org>
- Date: Sun, 8 Feb 2015 21:38:37 -0800
- To: Francois Marier <francois@mozilla.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Francois Marier <francois@mozilla.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 would phrase these differently: 1a. The browser recognizes the algorithm by name, the algorithm is not considered secure, and the browser still implements the algorithm. 1b. The browser recognizes the algorithm by name, but the algorithm is not considered secure, and the browser no longer wants to implement the algorithm. 2. The browser does not recognize the algorithm, and thus it doesn't implement it. I suggest that for 1a, a warning be given in the developer console, but the browser should continue to enforce SRI just like it would for a secure algorithm. I suggest that for 1b, a warning be given in the developer console, and the browser treat it just like SRI isn't being used. I suggest that for 2, a warning be given in the developer console. By default the browser should treat the fetch as though the integrity check failed (fail closed), on the assumption that the unrecognized name was probably a typo or other developer error. However, there should be some mechanism for the web page to tell the browser that the use of some unrecognized digest algorithm names is intentional and should be treated like case 1b. For example, <meta name=secure-digest-algorithms content="sha256 sha3-256 sha2-512/256">. Cheers, Brian
Received on Monday, 9 February 2015 05:39:08 UTC