I second that concern. I know at least one organization that is not going to consider implementing key pining precisely for that reason. They may consider a report-only mode, but as they were badly bitten by browser bugs in the report-only mode implementation of Content-Security-Policy that effectively changed report-only into enforcing, they would wait with that until the implementation matures.
I think it would be easier to convince them if they could implement key pinning themselves in incremental steps. For example, a browser can provide JS API to access certificate chain and a possibility to "pin" a particular JS source so it would be always executed from the local cache. On 25 May 2014 22:45, Yoav Nir <[email protected]> wrote: > Hi > > We’ve had a few threads ([1]) on this list about administrators needing to be > careful when activating HSTS and/or HPKP, because a common mistake like > forgetting to replace the certificate in time can brick your site. The usual > conclusion was that companies and organizations without the proper technical > capacity to maintain a valid certificate should not use these features ([2]) > > So today we got a real live demo how this can happen even to big, well-funded > companies ([3]). HSTS and HPKP were not involved - this was not a browser, > but a client that was programmed to hard-fail when receiving an expired > certificate. It is the equivalent of a site with HSTS, and if it can happen > to them, it could happen to anybody. > > I’m not saying we should revisit our previous decisions. Obviously Apple can > fix this now in minutes (probably already has), and all the consequences are > some bad press. I just think it is illuminating that even at large companies > there is no guarantee that an action that needs to be performed once a year > will be done correctly. > > Yoav > > [1] http://www.ietf.org/mail-archive/web/websec/current/msg01119.html (just > an example - there were many threads) > [2] http://www.ietf.org/mail-archive/web/websec/current/msg01213.html > [3] http://www.macrumors.com/2014/05/25/apple-software-update-invalid/ > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
