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

Marsh Ray <> Mon, 29 March 2010 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B7613A689A for <>; Mon, 29 Mar 2010 13:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.055
X-Spam-Status: No, score=0.055 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ydfG49QHpe6y for <>; Mon, 29 Mar 2010 13:01:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DA6D73A680F for <>; Mon, 29 Mar 2010 13:01:51 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1NwLAA-000CpI-VQ; Mon, 29 Mar 2010 20:02:19 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id E450E60B8; Mon, 29 Mar 2010 20:02:17 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1+M0B6080YI4hj5Rhg7z7EjJirB/+zBUPQ=
Message-ID: <>
Date: Mon, 29 Mar 2010 15:02:17 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Kyle Hamilton <>, "" <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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: Mon, 29 Mar 2010 20:01:53 -0000

On 3/29/2010 2:36 PM, Kyle Hamilton wrote:
> Of course, requiring the client to identify itself before proceeding
> with a handshake... that's something I wish that TLS provided for.

That should be supported by the TLS protocol, although you will need the
TLS library to call back into your code to give you a chance to abort
the handshake.

Nothing prevents you from defining an application protocol which assigns
the roles of TLS client and TLS server opposite from the underlying
transport layer. E.g., client makes a TCP connection to server, then the
TCP server sends a Client Hello to the TCP client. Once that connection
was established you could renegotiate to get mutual authentication.

You might have the client send a little initial hint if you want session
resumption to work in the usual direction. That's not part of TLS, but
it's not much different than using starttls in the middle of some other

- Marsh