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

Bruno Harbulot <> Tue, 30 March 2010 00:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54C743A63EC for <>; Mon, 29 Mar 2010 17:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.469
X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KtrEcoXGk756 for <>; Mon, 29 Mar 2010 17:22:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 022133A6AD0 for <>; Mon, 29 Mar 2010 17:22:35 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <>) id 1NwPEM-0009ig-5f; Tue, 30 Mar 2010 01:22:54 +0100
Received: from ([]:49356 helo=mymachine) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1NwPEL-0004Ao-UO; Tue, 30 Mar 2010 01:22:54 +0100
Message-ID: <>
Date: Tue, 30 Mar 2010 01:22:50 +0100
From: Bruno Harbulot <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: Bruno Harbulot from (mymachine) []:49356
X-UoM: Scanned by the University Mail System. See for details.
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: Tue, 30 Mar 2010 00:22:44 -0000


On 27/03/2010 01:14, Martin Rex wrote:
> 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.

A browser that would know it has no certificate to send would also know 
it doesn't need to prompt the user for one. As such, it could just send 
an empty Certificate message in response to the CertificateRequest 
(which is what already happens in Firefox, if you choose 'ask me which 
one to choose' and press 'Cancel'), without offering the user to choose 
a certificate amongst an empty list. That sounds purely a user-interface 
problem, then.
What would such a ClientHelloExtension add for this purpose (except 
saving a few bytes... although it seems that the CertificateRequest 
message can be one of the largest during the handshake if the 
certification_authorities list is long)?

Best wishes,