On 03/25/2014 04:21 PM, Bjoern Hoehrmann wrote: > * Trevor Perrin wrote: >> I didn't see where the spec handles an unrecognized hash algo >> different from absent integrity info? > > The point of the example is that an implementation would need to know > which attributes carry integrity information, which is simple with an > `integrity` attribute and impossible with your scheme; there is no need > for the specification to demand any specific behavior; as an example, a > browser vendor might decide never to make the address bar "green" when > there is integrity information the browser cannot verify (because the > scheme is unknown); there is no need to codify that in the standard. I disagree that the standard shouldn't weigh in here. site operators need to have a sense of how these directives will be interpreted. there are three cases that seem to need clearer specification, especially in the context of : 0) what should a user agent do if it sees an integrity algorithm that it does not know anything about? 1) what should a user agent do if it sees an integrity algorithm that it *does* know something about, but has reason to believe is compromised or worthless from a security perspective (e.g. sha256 truncated to 32 bits)? 2) what should a user agent do if it sees multiple integrity elements? (this is issue 4 in http://www.w3.org/TR/2014/WD-SRI-20140318/, i think) answering these questions with simple statements about what integrity state should apply (indeterminate, pending, corrupt, and intact) might be enough, but we should be clear about it. Site operators need to think through the consequences of their decisions in the face of browser upgrades that have new knowledge about hash algorithms we didn't know before, unupgraded browsers that only know about the MTI algorithms, and so on. --dkg
Received on Tuesday, 25 March 2014 21:32:08 UTC