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

Martin Rex <> Fri, 26 March 2010 23:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C9113A68D6 for <>; Fri, 26 Mar 2010 16:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.239
X-Spam-Status: No, score=-7.239 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_50=0.001, 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 yXacLqMMVWHW for <>; Fri, 26 Mar 2010 16:41:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 66DB13A6782 for <>; Fri, 26 Mar 2010 16:41:16 -0700 (PDT)
Received: from by (26) with ESMTP id o2QNfVHG001490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Mar 2010 00:41:31 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Story Henry)
Date: Sat, 27 Mar 2010 00:41:29 +0100 (MET)
In-Reply-To: <> from "Story Henry" at Mar 24, 10 11:49:05 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: Fri, 26 Mar 2010 23:41:17 -0000

Story Henry wrote:
> > 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...
> > 
> >  - the TLS client can not indicate that it posseses a client cert
> >    (so a server has to probe--and by probing create a
> >     bad user experience for users without client cert)
> >    TLS renegotiation has been abused in the past to reduce the
> >    bad user experience side of the problem.
> > 
> >  - the TLS client can not indicate that it does _not_ posess or
> >    is firmly determined to not send a client cert
> > 
> >  - the TLS server can not recommend to the TLS client that the client
> >    should offer a user a possibility to change his selection of
> >    client certificate for the current handshake.
> Yes. I am now looking for hacks to help people with defective browsers 
> participate in a world of secure client certificates. The only one up 
> till now I found was to have multiple server ports open each with a 
> different server key. 

You mean a server listening on multiple TCP ports for HTTP-over-TLS
incoming requests, with different TLS server certificates for each
of these TCP ports and different requirement levels for client certificate?

The purpose of "different server certs for each TCP port" is not clear
to me.  rfc-2818 server endpoint identification does not distinguish

Depending on how much cross-referencing there is from the content
on those different ports, and how much parallel access there is
from a single user to contents on seperate ports, you may run into
a TLS session caching issue with some browsers.  Some Web Browsers
do not distinguish TCP server ports (present in the URL)
in their client side TLS session caching.  Some blindly assume
that servers on the same host share their TLS session cache
and therefore exhibit frequent full TLS handshakes when
multiple distinct servers on the same host are concurrently
accessed (and probably flushing each TLS session where TLS session
resume fails).