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

Henry Story <henry.story@bblfish.net> Tue, 26 July 2011 02:34 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 9010A21F8C19 for <tls@ietfa.amsl.com>; Mon, 25 Jul 2011 19:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.261
X-Spam-Level:
X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 alBkLPp9S99K for <tls@ietfa.amsl.com>; Mon, 25 Jul 2011 19:34:15 -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 6349A21F8C15 for <tls@ietf.org>; Mon, 25 Jul 2011 19:34:15 -0700 (PDT)
Received: by wwe5 with SMTP id 5so14124wwe.13 for <tls@ietf.org>; Mon, 25 Jul 2011 19:34:14 -0700 (PDT)
Received: by 10.227.173.201 with SMTP id q9mr4571625wbz.92.1311647652757; Mon, 25 Jul 2011 19:34:12 -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 b13sm19770wbh.7.2011.07.25.19.34.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 19:34:11 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <201107252351.p6PNphFS006385@fs4113.wdf.sap.corp>
Date: Tue, 26 Jul 2011 04:34:09 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <13CDC8F7-572C-43C6-9123-29E291B4132B@bblfish.net>
References: <201107252351.p6PNphFS006385@fs4113.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1244.3)
Cc: tls@ietf.org
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: Tue, 26 Jul 2011 02:34:16 -0000

On 26 Jul 2011, at 01:51, Martin Rex wrote:

> Anders Rundgren wrote:
>> [snip]
>> That the TLS CCA protocol doesn't even support "Logout" haven't made
>> it a logical choice for web developers either.
> 
> Huh?  I have no clue what you're talking about.
> 
> If the server wants to perform a logout operation,
> it can delete the TLS session cache entry on the server.
> 
> But the Single Sign-On capability of the TLS client cert means
> that as long as the client credential is still available to the
> TLS client, the client will perform "transparent" reauthentication.
> 
>> The button "Clear SSL state" in MSIE is an indication how horribly bad it
>> can go when security experts design systems for "people".
> 
> Is your intention to get prompted again?
> From a usability standpoint, we prefer the "select automatically"
> setting and spare our users the client certificate selection popup.


The way to solve both of those issues is just a better User Interface.
At the Identity in the Browser W3C Workshop earlier this year [1]
we pointed to the work of Aza Raskin who showed very simply and clearly
what needed to be done:

   http://www.azarask.in/blog/post/identity-in-the-browser-firefox/

The user in the browser should be aware for ever tab what client certificate
he is using for the content he is seeing, just as he is aware of the server 
identity. This would make logging out, a one click affair controlled from
the browser - the only place where that can be done correctly.

   Is there anything we can do to persuade browser vendors to put 
more energy into solving this issue?

	Henry




[1] http://bblfish.net/blog/2011/05/25/

Social Web Architect
http://bblfish.net/