Re: [TLS] HTTPS client-certificate-authentication in browsers

Henry Story <henry.story@bblfish.net> Wed, 27 July 2011 07:23 UTC

Return-Path: <henry.story@bblfish.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204C721F8AA8 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 00:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.396
X-Spam-Level:
X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEDSyZTWycFP for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 00:23:39 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E32D621F8AAC for <tls@ietf.org>; Wed, 27 Jul 2011 00:23:38 -0700 (PDT)
Received: by wwe5 with SMTP id 5so720231wwe.13 for <tls@ietf.org>; Wed, 27 Jul 2011 00:23:37 -0700 (PDT)
Received: by 10.217.6.81 with SMTP id x59mr5751845wes.50.1311751417618; Wed, 27 Jul 2011 00:23:37 -0700 (PDT)
Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id k9sm840211weq.3.2011.07.27.00.23.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 00:23:36 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1244.3)
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <4E2F5BA0.4020507@fifthhorseman.net>
Date: Wed, 27 Jul 2011 09:23:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3553F681-866E-4068-A4C9-C205529E4328@bblfish.net>
References: <201107261911.p6QJB3Dv011457@fs4113.wdf.sap.corp> <4E2F1B65.2080404@telia.com> <4E2F5BA0.4020507@fifthhorseman.net>
To: tls@ietf.org
X-Mailer: Apple Mail (2.1244.3)
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 07:23:40 -0000

On 27 Jul 2011, at 02:28, Daniel Kahn Gillmor wrote:

> On 07/26/2011 09:54 PM, Anders Rundgren wrote:
>> It actually quite hard writing an HTTPS CCA based web app that
>> has similar login and session characteristics as one using password
>> authentication.
> 
> What's so hard about it?  Designate a URL (e.g.
> http://example.com/login) that triggers a request for client-side
> certificates.  When the user visits that URL with an acceptable
> client-side certificate, set a session cookie, and redirect them back to
> the page they were coming from.
> 
> When the user is not logged in, show them a login link that points to
> the designated URL.
> 
> When they are logged in, show them a logout link that takes them to a
> URL that clears the session cookie.
> 
> Am i missing something that makes this approach difficult or wrong?

I think the logout piece is not very well known. I only just discovered it
a few weeks ago, and have not tried it yet.  Anders pointed this out to me
that the following works in browsers for logout.

    if (document.all == null) // FF, Opera, etc
      {
         if (window.crypto) window.crypto.logout();
      }
    else // MSIE 6+
      {
         document.execCommand('ClearAuthenticationCache');
      };

( I spent a lot of time looking to see what could be done with throwing 
error conditions on the TLS level, and there most browsers don't seem
to respond correctly )

But apart from that, you are right it is not very complex. Perhaps what slows 
things down a lot are server side certificates, which need to be bought 
(though there is a free CA),  are more complex to set-up. But this kind of 
thing could be automated easily as soon as the usefulness of this method of authentication 
were demonstrated by some large services. Also DNSsec and DANE will remove
some obstacles described by Dan Kaminsky presented by having CAs in the
first place. So things will in fact get simpler from now on.

Even creation of client side certificates is really easy, once one
has located the client libraries, one knows about keygen and one has
the javascript for the IE version. Client side certificates is a one click of a 
button affair in fact.

So there is a big part of eduction that is the issue in the so
called complexity of CCA. There are much more complex things out there,
with thousands of engineers finding no trouble learning those.

-----------------------------
What is missing: the use case
-----------------------------

But what is missing in CCA is the use case. The problem is that if you
use CCA then you can also use password authentication. And because for
the most part CCA only logs you into *one* server - the one that gave you the
Certificate - you gain little advantage over password authentication. And
where there is no benefit to be gained, it is very difficult to explain
something to people - both end users and developers of the feature. Take
this together with the confusion about the idea that one has to keep
one's certificate secure and one has created a huge amount of confusion.

So the important thing is to create a use case that takes client certificates
from where they are, to being one million times more valuable, while remaining
zero cost. This is what http://webid.info/ - a W3C project - allows. By placing a
WebID into the subject alternative name of the X509 we get the following advantages:

 - the same certificate could then be used to login to every site on the web
 - attributes about the user need not be placed in the certificate but can be placed 
   on the web, where they can be access controlled
 - it is dead easy to do certificate revocation: just remove the public key from the profile
   document.

Here the value of certificates really starts to shine. But we need to bootstrap
this to make the point clearly. So please help us by developing more fun usages
of  WebID.

Here is the simplest paper:
   http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_22/webid.html

Henry


> 
> 	--dkg
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

Social Web Architect
http://bblfish.net/