Re: Client Certificates - re-opening discussion

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
>> On 17 Sep 2015, at 23:10, Mark Nottingham <[e-mail]> 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 
> [e-mail] [1] and [e-mail] 
> 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/