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

Anders Rundgren <> Wed, 27 July 2011 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10CFF11E80F2 for <>; Wed, 27 Jul 2011 12:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.413
X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FqekiEY59+af for <>; Wed, 27 Jul 2011 12:33:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0BF2711E80AD for <>; Wed, 27 Jul 2011 12:33:04 -0700 (PDT)
Received: from [] ( by (8.5.133) (authenticated as u36408181) id 4E305E9700002421; Wed, 27 Jul 2011 21:33:02 +0200
Message-ID: <>
Date: Wed, 27 Jul 2011 21:32:45 +0200
From: Anders Rundgren <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jul 2011 19:33:05 -0000

On 2011-07-27 20:34, Martin Rex wrote:
> Anders Rundgren wrote:
>> AFAICT you indirectly say that the de-facto standard for maintaining
>> (note, not creating) secure sessions on the web, i.e. server-side
>> HTTPS + session cookies is inferior.
> Huh?  I'm completely lost.

Pardon me if I read too much into your response.

> If you want to do application-level session management, then you
> ought to do application level session management, and NOT try to
> mess around and interfere with Single Sign-On functionality at the
> transport layer.

Sure, but the question was to use client-side PKI in such an application.
And most of all, how to do it in a such way the the applications
doesn't get affected.

> Even in closed environments, where TLS client certificates are used
> for Single Sign-On, there usually is a fallback capability to use
> passwords as well as support for migration from pure-password-based
> logons to cert-based logons, and during the transition, both
> authentication schemes must be supported in parallel.

See previous section.

> So the only sensible application level session management is doing
> it uniformly at the application level independent of whether the
> user authenticated via password (which he may have to re-enter
> occasionally), or via some Single Sign-On functionality -- be it
> TLS client certs or HTTP Negotiate, or potentially other schemes
> (saml, oauth).

This is exactly what I want. Unfortunately as I have described
earlier, this is easier said than done using the currently only
standardized CCA method.

Without a server-initiated "logout" added to TLS it can never
be done in a portable way.  But as we (all) know the vendors
doesn't care **** about CCA on the web.

> You really don't want having to redesign & update the installed base
> whenever you're adding support for a new authentication scheme,
> therefore messing around with authentication scheme internals
> when all you want to do is application level session management
> seems to be an unconditionally bad idea.

Of course nobody wants to redesign the applications.

>> The fact is that exactly $0 has been spent by the people building and
>> defining the TLS/HTTPS platforms on *researching* the issues I mentioned,
>> while *hundreds of millions of dollars* has been spent on *code* that
>> merges client-side PKI and the web in other ways than using HTTPS CCA.
> HTTPS CCA is a means to use Single Sign-On (using X.509 certs for
> online authentication) and equivalent to using Kerberos with
> HTTP Negotiate or Kerberos with other protocols.
> You seem to be entirely mislead about the purpose and usage constraints
> of X.509 when used for GSS-API based Single Sign-On or TLS Single Sign-On.

Purpose is an opinion.
IMO, HTTPS CCA as an enterprise SSO-solution sucks ***.
As a one-to-many-independent-RP-sign-in it does OK.

> It has _NOTHING_ to do with digital signatures and can not be used
> to authorize individual transactions.

We are not talking about me; we are talking about hundreds of banks.

> The only reliably means to ensure that a "proof of identity" can NEVER
> be confused (or maliciously abused) with an explicit authorization
> for some transaction is to use distinct PKI credentials, distinct
> protocols and distinct credentials management functions.
> If PKI credentials, protocols or credentials management for these
> completely distinct purposes are conflated, huge risks and damages
> will ensue, and people will get hurt badly.

They typically use the same certificate for app-level auth as for
HTTPS CCA.   They do (in the rare case specific signature applications
are supported), provide certificate with the NR bit set for those.