On 03/21/2014 03:49 PM, Hill, Brad wrote: > WebSec WG members, > > The WebAppSec WG at the W3C has recently announced a First Public Working > Draft for "Subresource Integrity". > > http://www.w3.org/TR/SRI/ > > This specification describes a method to add metadata about the hash > identity of resources (like script files and images) to HTML and specify > policy about how to verify and manage such resources before they are added to > a web resource's Document Object Model.
thanks for this heads-up about this draft. I'm glad to see more work in this area. a few concerns spring to mind: handling cross-origin errors ----------------------------- section 6.3 mentions cross-origin data leakage -- i'm glad to see this discussed. However, it suggests that UAs SHOULD refuse to fire error events on cross-origin resources. This contradicts section 3.5.4, which claims that if the C-S-P of the origin page has a failure-mode of "block" or "fallback" (the only values available?) then the UA MUST report a violation. "report a violation" itself is linked to http://www.w3.org/TR/CSP11/#dfn-report-a-violation, which says the UA MUST fire a violation event. how is a UA expected to resolve these contradictions? Or am i missing some nuance that makes these non-contradictory? hash algorithm agility ---------------------- hash function agility raises questions about future interactions; I'm glad to see it mentioned in section 6.2, but i don't think the text there is sufficient. let's imagine a future where SHA-256 is deemed to be broken; how should a user-agent deal with elements with an SHA-256-based integrity attribute? should the UA treat the element as though it had no integrity tag at all (value="indeterminate")? or should it treat the element as though it was compromised (value="corrupt")? If we choose value="indeterminate" and the origin's integrity-policy has "require-for-all", what should happen? being explicit about how we will handle algorithm deprecation in the future will make future transitions much less painful. regards, --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
