Re: [TLS] Asking the browser for a different certificate

Martin Rex <> Sat, 27 March 2010 01:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47C9D3A6898 for <>; Fri, 26 Mar 2010 18:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.419
X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6MeQsvdqtIPN for <>; Fri, 26 Mar 2010 18:14:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B69233A6882 for <>; Fri, 26 Mar 2010 18:13:55 -0700 (PDT)
Received: from by (26) with ESMTP id o2R1EBJj024491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Mar 2010 02:14:11 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Peter Gutmann)
Date: Sat, 27 Mar 2010 02:14:10 +0100 (MET)
In-Reply-To: <> from "Peter Gutmann" at Mar 24, 10 06:11:44 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Subject: Re: [TLS] Asking the browser for a different certificate
X-Mailman-Version: 2.1.9
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: Sat, 27 Mar 2010 01:14:05 -0000

Peter Gutmann wrote:
> Martin Rex <> writes:
> > 
> >IMHO there are a number of defects in the TLS protocol related to client
> >certificate authentication, and some of them should probably be fixed at the
> >TLS protocol level.  But fixes at the TLS protocol level may take a huge
> >amount of time before they become a useful feature in the installed base...
> Yeah, because this is going to affect the vast numbers of users of
> SSL client certs :-).

The non-users of SSL client certs are much more affected.

Currently, if you enable a Web Server to request a client cert
in the initial handshake, the users without SSL client cert suffer
the worst user experience of all.  Would the browser be able to
tell the server in a ClientHelloExtension "Don't bother sending
me a CertificateRequest, because I don't have one", then
the server could skip the CertificateRequest message if the
application/configuration allows the handshake to complete without
client certificate.

> >[Issues]
> Couldn't a lof of this be handled via TLS extensions?

Sure.  Preferably with one single TLS extension that carries all the
necessary signals.