Re: Client Certificates - re-opening discussion

> 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

Social Web Architect
http://bblfish.net/

Received on Friday, 18 September 2015 15:57:24 UTC