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

Anders Rundgren <anders.rundgren@telia.com> Mon, 25 July 2011 13:38 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 E5F8C21F8B0C for <tls@ietfa.amsl.com>; Mon, 25 Jul 2011 06:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.425
X-Spam-Level:
X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 Nb1RfIRxicDM for <tls@ietfa.amsl.com>; Mon, 25 Jul 2011 06:38:47 -0700 (PDT)
Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id B81C821F8B15 for <tls@ietf.org>; Mon, 25 Jul 2011 06:38:46 -0700 (PDT)
Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B00DAF446; Mon, 25 Jul 2011 15:38:45 +0200
Message-ID: <4E2D71DB.6020604@telia.com>
Date: Mon, 25 Jul 2011 15:38:35 +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> <4E2D688E.5030509@telia.com> <E2962F5B-AD7C-4AF7-9548-9686CE14FF38@bblfish.net>
In-Reply-To: <E2962F5B-AD7C-4AF7-9548-9686CE14FF38@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 13:38:48 -0000

On 2011-07-25 15:05, Henry Story wrote:

>> If there had been a *single* mainstream service of US origin who used
>> HTTPS CCA this would be fixed in record time.
> 
> What about the army? They are pretty big in the US, representing a huge portion
> of the budget I believe.

Yes, but the army has IT-staff that takes care of "issues", consumers
do not.  The army is also much less fuzzy about inconvenience.

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


> I believe that is only because of the naming problem. Distinguished Names of companies
> don't scale to the world.

There are actually several other problems that are much worse.
On my wife's firefox the bank have deployed two certs and
both of the show up when she is going to login.  If she
takes the one marked "non-repudiation" you get a security
error that only experts understand.


>> TLS' session context is incompatible with web sessions.

> Why?  A TLS Session can work very well with web sessions. You can 
> just make your TLS session be a web session.

AFAIK HttpSession.invalidate in Tomcat/JBoss has no effect whatsoever
on a TLS session.


>> 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.
> 
> yes, but there is no argument for why this is the case. And you don't 
> even consider http://webid.info/

WebID isn't diminished by this.  It just gets better :-)


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

> IT's odd that people want to move away from something that is close to working.
> I wonder why... What is the agenda?

They have given up on this.
"Close to working" isn't good enough.

Anders

> 
> 
>     Henry
>>
>> 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/
>>>
>>>
>>
> 
> Social Web Architect
> http://bblfish.net/
> 
>