- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 18 Sep 2015 13:05:14 -0400
- To: Henry Story <henry.story@co-operating.systems>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Henry, Thanks, but this is a much more narrowly-scoped discussion -- how to make client certs as they currently operate work in HTTP/2. At most, I think we'd be talking about incrementally improving client certs (e.g., clarifying / optimising the scope of their applicability -- and that really just is an example, not a statement of intent). Cheers, > On 18 Sep 2015, at 11:53 am, Henry Story <henry.story@co-operating.systems> wrote: > > >> On 17 Sep 2015, at 23:10, Mark Nottingham <mnot@mnot.net> wrote: >> >> Hi, >> >> We've talked about client certificates in HTTP/2 (and elsewhere) for a while, but the discussion has stalled. >> >> I've heard from numerous places that this is causing Pain. So, I'd like to devote a chunk of our time in Yokohama to discussing this. >> >> If you have a proposal or thoughts that might become a proposal in this area, please brush it off and be prepared. Of course, we can discuss on-list in the meantime. >> >> Cheers, >> >> -- >> Mark Nottingham https://www.mnot.net/ > > > Apart from the proposals as the proposal by Martin Thomson > and the follow up work referenced earlier in this thread > by Mike Bishop [1], I'd like to mention more HTTP centric > prototypes which would rely perhaps not so much on certificates, > but on linked public keys, that build on existing HTTP > mechanisms such as WWW-Authenticate, which if they pass security > scrutiny would fit nicely it seems to me with HTTP/2.0 . > > • Andrei Sambra's first sketch authentication protocol > https://github.com/solid/solid-spec#webid-rsa > > • Manu Sporny's more fully fleshed out HTTP Message signature > https://tools.ietf.org/html/draft-cavage-http-signatures-04 > > These and the more TLS centric protocols require the user > agent to be able to use public/private keys generated by > the agent, and signed or published by that origin, to > authenticate or sign documents across origins. > > This is where one often runs into the Same Origin Policy (SOP) > stone wall. There was an important discussion on > public-webappsec@w3.org [1] and public-web-security@w3.org > entitled > > "A Somewhat Critical View of SOP (Same Origin Policy)" [2] > > that I think has helped clarify the distinction between Same Origin > Policy, Linkability, Privacy and User Control, and which I hope > has helped show that this policy cannot be applied without > care nor can it apply everywhere. > > The arguments developed there should be helpful in opening discussion > here and elswhere too I think. In a couple of e-mails in that > thread, I went into great detail showing how SOP, linkability and User > Control and privacy apply in very different ways to 4 technologies: > Cookies, FIDO, JS Crypto API and client certificates [3]. This shows > that the concepts don't overlap, two being technical and the two > legal/philosophical, each technology enabling some aspect of the > other, and not always the way one would expect. > > Having made those conceptual distinctions I think the path to > acceptance of solutions proposed by this group will be much eased. > > Looking forward to following and testing work developed here, > > All the best, > > Henry > > > [1] • starting: https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0558.html > • most recent by Mike Bishop > https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0310.html > [2] https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/ > [3] https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0101.html > which is in part summarised with respect to FIDO in a much shorter > email > https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0119.html > -- Mark Nottingham https://www.mnot.net/
Received on Friday, 18 September 2015 17:05:39 UTC