W3C home > Mailing lists > Public > public-xg-webid@w3.org > November 2011

Re: [http-auth] Fwd: [TLS] HTTPS client-certificate-authentication in browsers,

From: Henry Story <henry.story@bblfish.net>
Date: Fri, 4 Nov 2011 12:09:23 +0100
Message-Id: <610CA253-E9FA-4B15-9DB5-BA19C2F2C697@bblfish.net>
To: http-auth@ietf.org, WebID XG <public-xg-webid@w3.org>

  ( I just subscribed to this list so I was not able to reply-to the original post, and so the threading might be a bit askew. )

Let me first present myself quickly. I am currently chairing the W3C WebID XG group which has a nice little introductory video on http://webid.info/ , and a spec that is slowly developing at http://webid.info/spec/ . It is worth looking a bit longer that way, because there is a lot of hidden power in TLS that we have been discovering, which makes all kinds of very interesting things possible. 

On Novermber 4th 2011, Yoav Nir <ynir at checkpoint.com>
> I'm pretty sure that if client certificates worked for HTTPS, we would not have an HTTP-AUTH initiative.

So I hope we don't have to open this discussion in such a polarising way. There is nothing to say that WebID/TLS cannot be compatible with client auth, indeed it never occurred to me that it should not be.

The above statement also assumes that nothing new can come to light from well known quarters. Yet for hundreds of thousands of years the earth man walked on was round and yet few people took much notice [1] : the earth being round for example was not hidden in any way to humanity. And here I hurry to add that I am not saying that HTTP Auth is in the flat earth camp! But if we start off by assuming that we can't discover something new from unexpected quarters, and we justify that by the fear that this new thing may put too much in question, then though this is quite a well trodden path in the history of humanity, it is certainly not the attitude that let to the discovery of the Americas and so the foundation of the IETF :-)

> But the biggest thing working against certificates is that they identify a device, not a user.

A certificate identifies a person in possession of the private key of a given public key. That this is best done via devices is another thing. On this reasoning someone's signature does not identify the person, but the pencil they used to sign. 

> If I have several devices then I either have to have multiple copies of my cert and private key, or several different certificates, one for each device, or an n+1-th device (such as a USB token) that contains the private key and can be connected to any browser, and there's no technology now that would work with all browsers.

It is true that if a certificate can only be used on one web site, then this is a problem because the advantage they provide is so infinitely small. But this is no longer the case once WebID enters the scene. A WebID certificate can be used on every web site: so the benefit had by putting the certificate on different devices then becomes justifies. When that is taken into account, and the ease of certificate creation is understood, then you can see how both your position and the WebID procedure can be right.

It is also worth seeing that certificate creation is not that difficult. In addition to the video mentioned above, here is a video that shows how one can create a certificate in one click in a number of browsers easily


It does rely on the use of a temporary key, to help switch between devices. One time keys can be sent via cell phones or other means. 

> It's little wonder that all the big services prefer to use passwords.

The reason service providers prefer to use passwords is, as mentioned above, quite other. It is that client certificates are not of much use in addition to passwords if the certificate can only be used on one web site. Your point about the complexity of getting certificates onto different devices you explained above is well taken. But when the ease of creating a certificate is then combined with the value gained from using it, then those issues disappear in practical importance.

I wrote this up as a FAQ here

So hopefully I have been able to phrase these rebuttals in such a way as to make in both understandable why these misunderstandings exist and why one can in fact solve the problems of client certificates with hardly any changes.

> Yoav
> On Jul 25, 2011, at 9:36 AM, Peter Saint-Andre wrote:
> > Might be of interest here...
> > 
> > -------- Original Message --------
> > Subject: [TLS] HTTPS client-certificate-authentication in browsers
> > Date: Mon, 25 Jul 2011 14:06:59 +0200
> > From: Anders Rundgren <anders.rundgren at telia.com>
> > To: tls at ietf.org
> > 
> > Hi Guys,
> > I don't really know who "owns" this question but presumably you do...
> > 
> > HTTPS client-certificate-authentication in browsers
> > ===================================================
> > I don't believe that TLS CCA (Client Certificate Authentication) in the
> > form of HTTPS as implemented in current browsers has much of a future.
> > 
> > In fact, quite a bunch of the entities in the EU working with consumer PKI
> > have replaced HTTPS CCA with an application level scheme which wasn't such
> > a big deal since they anyway were forced writing a browser PKI client more
> > or less from scratch since the ones shipped with browsers doesn't support
> > PKI as defined by banks and government (like mandatory PIN codes also
> > for on-line enrolled keys).
> > 
> > That the TLS CCA protocol doesn't even support "Logout" haven't made
> > it a logical choice for web developers either.  Well, there are some
> > workarounds but they are by no means straightforward, supported
> > out-of-the-box by server authentication schemes, and are (of course)
> > entirely undocumented.

The logout code that works in IE and Firefox is

function logout(elem) {
  if (document.all == null) {
     if (window.crypto) {
             return false; //firefox ok -- no need to follow the link
         } catch (err) {//Safari, Opera, Chrome -- try with tis session breaking
     } else { //also try with session breaking
  } else { // MSIE 6+
     return false;
  return true


> > 
> > The button "Clear SSL state" in MSIE is an indication how horribly bad it
> > can go when security experts design systems for "people".
> > 
> > There's no way you can hide the fact that TLS CCA is only truly useful
> > securing tunnels between "boxes".
> > 
> > Anders

[1] http://bblfish.net/blog/page7.html#2005/06/24/12-54-28-860

Social Web Architect
Received on Friday, 4 November 2011 11:10:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:48 UTC