Re: Perceived issues with TLS Client Auth

On 27 Sep 2012, at 11:35, Ben Laurie <benl@google.com> wrote:

> 
> 
> On 27 September 2012 10:19, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 27 Sep 2012, at 10:51, Ben Laurie <benl@google.com> wrote:
> 
>> On 26 September 2012 17:10, Henry Story <henry.story@bblfish.net> wrote:
>>> 
>>> On 26 Sep 2012, at 17:54, Ben Laurie <benl@google.com> wrote:
>>> 
>>>> On 26 September 2012 14:24, Henry Story <henry.story@bblfish.net> wrote:
>>>>> Here is how that would look if we were to  imagine a user (me) using Google+.
>>>>> 
>>>>> One day I go to google plus on my desktop browser and Google Plus entices me to
>>>>> "Use WebID and login securely across the web"
>>>>> I click on that banner, and pronto, a certificate is created and transferred to
>>>>> my browser. (ok perhaps you add an intermediate page with helpful explanations
>>>>> and cool demos)
>>>>> 
>>>>> Next I am walking down the street with my Android. Google+ is clever enough to notice that my android does not have a certificate - it does a TLS request for a client certificate, but receives none - and so asks me
>>>>> "Hi Henry, get a WebID certificate for your phone too"
>>>>> I click the banner and oops I have a certificate in Android.
>>>>> 
>>>>> Once I have a certificate for a device, I can log into any web site that supports WebID in one click. I can also determine for any site how much information I wish to give that site about me - using access control on information at my profile. Someting we need to work on still.
>>>> 
>>>> You seem to have missed out a step - how do these web sites know about
>>>> my new WebID?
>>> 
>>> In the scenario described I get my (personal) WebID from Google+ . If I were employed by the W3C I would then get a professional WebID by doing the same procedure on my W3C profile page.
>>> 
>>> So I then go to say the WebSite of a friend of mine who has his personal web server, at a domain
>>> joe.name . When I arrive on the front page of https://joe.name/ that site does not ask me to log in,
>>> it gives me public information that joe is happy for anyone to know. Then perhaps I want to login, so I click
>>> the login button, and this sets up a procedure described in the spec
>>> 
>>>   http://www.w3.org/2005/Incubator/webid/spec/#connecting-at-the-application-layer
>>> 
>>> which starts with a TLS renegotiation and a request for the client certificate as explained in the TLS spec.
>> 
>> How does joe.name know this certificate represents you?
> 
> 1. Through TLS his server knows that I have the private key of the public key in the certificate.
> 2. The verification of the WebID is then done by follwing the procedure described here
>    http://www.w3.org/2005/Incubator/webid/spec/#verifying-the-webids
> 
> Right - so the steps you missed are where the WebID profile gets updated to include the new key, and where joe.name somehow (how?) decides that this WebID is allowed to log in...

Because the new certificate I received from my server, contains the same WebID as the old certificate. The public key changed (and so  the certificate too of course )  but the WebID remains the same :-)

So for a same id, what remains the same across each certificate, in whatever device it happens to be, is the Subject Alternative Name, the URI that refers to me: the WebID.

It is true that we don't talk about multiple certificates in the spec. I was thinking it should be updated to show the same WebID can have multiple public keys, and multiple associated certificates. This discussion shows that this may need to be drawn out a lot more. 

>  
> 
>> 
>>> If that results in no certificate a pop up can appear, and any number of other authentication systems can be proposed to the user.
>>> 
>>>> 
>>>> Also, if I've been using WebID to log into google for some time, and
>>>> my Android phone is new, how do I get logged into G+ in order for
>>>> Google to notice that I do not have a cert?
>>> 
>>> You use a password there for Google+ . Luckily you' only need one or two passwords, so those
>>> could be really long and easy to remember - and also dead safe. I don't think I heard that anyone had trouble connecting to Google+ at present with any number of devices, even though people have to remember passwords to do so?
>> 
>> People forget passwords all the time, even though they have to use
>> them regularly. The problem gets much worse for passwords that are
>> used rarely.
> 
> well use whatever procedures you are using now and adapt them. This is not a new problem,  and it is not the problem we are trying to solve. One could say indeed that this is a solved problem. I put my passwords in a key chain.
> 
>> 
>>> The issue we are trying to deal with is having to remember a password for all the other sites, and the duplication of information that comes with that, the lack of security this duplication brings, the centralisation of information that are the consequences of the difficulty of having all of the above be easy to use - and so the consequent loss of privacy. WebID solves the privacy problem, because it no longer requires centralisation of all information on one mega server, and it allows cross domain identification and cooperation. It helps create a Social Web, as opposed to a social network. (you will find more on that on my home page)
>> 
>> I totally understand the goals, and I have no argument with them. My
>> concerns are purely around usability. But apparently you don't want to
>> hear that - you think you have a usable solution. So what's your
>> explanation for lack of adoption?
> 
> The solution we are proposing cuts across domains very heavily: from TLS to UI to LinkedData. Most devs don't grok TLS that well. If they do, they don't tend to be good at UI. Rarely do they know LinkedData. None of these is difficult, once one has a few demonstrations. It is not unlike the difficulty people had explaining the web before Netscape came out. If you don't see it used you need to be the type of person who can project himself imaginatively into a new domain. Not everybody is like that.
> 
> The further problem is that these tools are making use of old technologies in new ways and so it requires a conceptual shift, not unlike the one involved in seeing a duck or a rabbit in the image below [1] 
> 
> <PastedGraphic-1.tiff>
> 
> And in many of these spaces people's attitudes to received wisdom is very hardened. So it is difficult to get them to make that shift. Add to that that there may be some perceived business interests in not shifting and one has an answer to your question. Notice that sometimes people do get it, but then they want to make a million out of it. I think that is what happened to the original developer assigned to bug  http://code.google.com/p/chromium/issues/detail?id=29784
> He left your company soon thereafter to work for a startup that was attempting to integrate all social networks into Google Chrome. 
> 
>   Anyway, lets leave it to the historians to understand why people could not see that the earth is round, or why they could not see that the earth was turning around the sun. When people moved form one to the other way of thinking nothing in reality changed. It could be that people in engineering are used to a new tool appearing to solve their problems, and that they tend to not consider that they could use the old tool they had in a new way. You could also ask: why did it take so long for AJAX to be used?
> 
> 	Henry
> 
> [1] https://blogs.oracle.com/bblfish/entry/foaf_ssl_pki_and_the
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/