Hi. Regarding what WebAppSec at the W3C is doing: Our proposed new charter in the WebAppSec WG, (http://lists.w3.org/Archives/Public/public-webappsec/2012Nov/att-0112/Web_Application_Security_Working_Group.htm) currently under W3C team review, has a deliverable that we've currently titled "Sub-Resource Integrity". It is intended to address security properties of Web Applications, specifically, to allow an application instance (DOM) created over an HTTPS connection to load other resources (images, javascript, etc.) over insecure transports or across administrative boundaries with a guarantee of integrity.
It's closest relation is Gerv Markham's Link Fingerprints (http://www.gerv.net/security/link-fingerprints/), although that focuses on integrity of linked content to be handled as disposition: attachment. We may or may not take on that as a "bonus feature" in WebAppSec, but it is not necessarily implied by the new proposed charter scope. Anyway - this all is to say that we are explicitly *not* addressing the same problem space as S-links. We are narrowly interested in protecting the integrity of a Web Application with components distributed across multiple administrative domains and/or insecure network links, but all trust would still bootstrapped initially over HTTPS. There is no intent to address problems of identity, trust bootstrapping, secure introduction, key pinning, etc. I think this list is a great place to start that conversation. Thanks, Joe! Brad Hill Co-Chair, W3C WebAppSec WG From: therightkey-boun...@ietf.org [mailto:therightkey-boun...@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, February 13, 2013 7:30 PM To: Joseph Bonneau Cc: therightkey@ietf.org; Stephen Farrell Subject: Re: [therightkey] New proposal: S-links (secure links) Well, I may be mistaken, or I may have mis-skimmed your proposal. To be more concrete: At the WebAppSec / WebCrypto meeting in November, it was mentioned (by Brad Hill IIRC) that one of the things that WebAppSec might be looking into after CSP would be link-based assertions. The example I remember is to attach a digest of the destination resource to a link, so that, e.g., if a third-party script were compromised, it could be recognized. Seems slightly different, but still related. In any case, might not hurt to ping the WebAppSec list as well as this one. Cheers, --Richard On Wednesday, February 13, 2013, Joseph Bonneau wrote: I believe some ideas of this character have been discussed in the W3C WebAppSec WG. http://www.w3.org/2011/webappsec/ Can you point to anything more specific? I discussed s-links via email with Adam Barth who's a CSP editor and it didn't seem that this has been extensively discussed by the WebAppSec WG... The only thing I can think of is discussion about enabling CSP to require that the same cert is presented for all page resources, which I believe didn't make the spec due to origin contamination problems. S-links, by the way, has the same issue unless a persistent key pin (or other persistent security upgrade) is immediately received, as discussed on the s-links site-this is a very important subtlety. Cheers, Joe _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
