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

Anders Rundgren <anders.rundgren@telia.com> Mon, 25 July 2011 12:59 UTC

Return-Path: <anders.rundgren@telia.com>
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 2370A21F88E5 for <tls@ietfa.amsl.com>; Mon, 25 Jul 2011 05:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.433
X-Spam-Level:
X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
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 0kKnVPJahqR6 for <tls@ietfa.amsl.com>; Mon, 25 Jul 2011 05:59:06 -0700 (PDT)
Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 9989C21F8834 for <tls@ietf.org>; Mon, 25 Jul 2011 05:59:06 -0700 (PDT)
Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0079C13B; Mon, 25 Jul 2011 14:59:04 +0200
Message-ID: <4E2D688E.5030509@telia.com>
Date: Mon, 25 Jul 2011 14:58:54 +0200
From: Anders Rundgren <anders.rundgren@telia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Henry Story <henry.story@bblfish.net>
References: <4E2D5C63.3000408@telia.com> <FCFA8791-E16A-45F4-B23D-B6A4A4F88AF9@bblfish.net>
In-Reply-To: <FCFA8791-E16A-45F4-B23D-B6A4A4F88AF9@bblfish.net>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Mon, 25 Jul 2011 12:59:08 -0000

On 2011-07-25 14:31, Henry Story wrote:
> Hi Anders, I kind of lurk here, but I don't think that client side
> CAs are impossible to get right in the browsers. They are pretty close
> to doing things right. Logout from the browsers would not be that difficult
> to do. I kept thinking that the W3C project http://webid.info/ could stimulate
> the improvement of these pieces.
> 
> But I would be interested in feedback from this list on the subject.

Hi Henry,

If there had been a *single* mainstream service of US origin who used
HTTPS CCA this would be fixed in record time.

The tenths of millions of users of "homegrown" PKI authentication schemes
in the EU and Asia apparently don't think HTTPS CCA is particularly useful,
neither do I.  TLS' session context is incompatible with web sessions.

For our mutual interest, PKI for consumers, it doesn't really matter what
the end-solution will be, but an educated guess is that will not build
on HTTPS CCA, but on HTTPS with + an application.  This is BTW pretty
much what has happened with HTTP auth versus form-based auth.

Fortunately this can be introduced without redeploying PKI so it is a
true "migration solution".

Anders

> 
> Henry
> 
> On 25 Jul 2011, at 14:06, Anders Rundgren wrote:
> 
>> 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 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
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> Social Web Architect
> http://bblfish.net/
> 
>