Re: Perceived issues with TLS Client Auth

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

> On 27 September 2012 10:47, Henry Story <henry.story@bblfish.net> wrote:
>> 
>> 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 :-)
> 
> OK, but that still leaves open the question of how joe.name gets hold
> of this WebID in the first place.

It is in the Subject Alternative Name position of the certificate as shown in the
spec section 2.1 
   http://www.w3.org/2005/Incubator/webid/spec/#the-certificate

> 
> Also for the WebID to remain the same, I have to remember what it is,
> right?

  No the WebID is in the Certificate hidden from the user. The browser
presents you with the Common Name (CN) of the Distinguished Name. You should
therefore make the CN be something easy to identify eg: 

   benl@google.com for your current work certificate
   benl@apache.org since you are a founding director of Apache
     ( http://en.wikipedia.org/wiki/Ben_Laurie )    

Or whatever fits into a CN field. In fact your certificate provider 
should help you make the right choice.

> If I visit joe.name and cannot log in because I have no cert, I
> have to somehow get a new cert issued with the right WebID (i.e. the
> one joe.name is expecting). How do I do that?

 If you lost your Google+ certificate you:
 
1. go to google+
2. login - if you lost your password, you get your social network to help you recover it
3. delete the old certificate listed there
4. get a new certificate

You can see this implemented very nicely by https://my-profile.eu/
Try it out now that he has fixed the problem you found yesterday. The only issue at present is that we don't have that many cool sites to log into. ( Though I think we are all here trying to fix this )

>> 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.
> 
> Well, hang on. For that to be secure, either the WebID profile must be
> updated to include the new public key, or joe.name has to check that
> it comes from the same issuer, and believe that this issuer has a
> secure issuance policy.


Indeed that is exactly what happens: the WebID profile is update to include the new  public key at the moment you make the public key, and create the certificate. All that is done in the one click procedure. The video in ogg, h.264 and webm video format is available here:

   http://bblfish.net/blog/2011/05/25/

shows exactly how that happens. 
Perhaps we should also write that part up on our wiki?

> 
>> 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/
>> 

Social Web Architect
http://bblfish.net/

Received on Thursday, 27 September 2012 10:15:24 UTC