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

Anders Rundgren <> Thu, 28 July 2011 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BB4821F8C66 for <>; Thu, 28 Jul 2011 02:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=-1.599, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 23+6IhZ6H5D6 for <>; Thu, 28 Jul 2011 02:54:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8952121F8C63 for <>; Thu, 28 Jul 2011 02:54:03 -0700 (PDT)
Received: from [] ( by (8.5.133) (authenticated as u36408181) id 4DF89E7F0080B529; Thu, 28 Jul 2011 11:54:01 +0200
Message-ID: <>
Date: Thu, 28 Jul 2011 11:53:46 +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
To: Stefan Winter <>
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: Thu, 28 Jul 2011 09:54:04 -0000

I'm happy that none the banks I have talked have any interests
in such crap.

The usage level of the German eID is hardly measurable either.


On 2011-07-28 11:19, Stefan Winter wrote:
> Hi,
>>>> Lots of banks wants to use CCA for their users.
>>>> That is a non sequitur.
>>>> Banks (here in Germany) have abandoned tradtional TANs based on
>>>> the unconditional presumption that client PCs are infested with
>>>> malware, and most banks in Germany are currently replacing indexed TANs (iTAN)
>>>> presumably based on the perception that malware on clients (trojans/phishing)
>>>> has caught up with iTAN procedure complexity.
>>>> At this point, with the presumption that all client PCs are
>>>> thoroughly infested with malware, going for a Single Sign-On
>>>> mechanism would be completely braindead and irresponsible.
>> So using client certificates for authentication is such a bad idea that
>> there is no point in looking into issues on how to make it better?
>> How is the German e-card supposed work then?
> Just trolling around on this list every now and then, but can't resist
> to comment because I got my new eID card and also HBCI access recently.
> eID: The electronic identity card contains lots of personal details
> about you in some credential storage. It must be put into a whitelisted,
> EAL-whatever certified hardware device, connected via USB. There is one
> well-defined application on your computer which can ask the reader to
> retrieve a *subset* of the personal information stored. Other
> applications on the computer talk to this one application via an API.
> Your card reader will present the name of the application which wants
> the data, the pieces of data it wants to have from your card, and will
> ask for your authorisation to reveal that personal data. That is done
> via display+PIN directly on the card reader; no secret information ever
> leaks the card reader unless authorized directly on the device by the
> user. [1]
> This exhibits a property of the system which plain presentation of a
> X.509 certs won't allow: send only a subset of the stored information.
> It was refreshing to see this in action when I got my reader last week:
> my car insurance website signalled they need my real name, birthdate and
> birthplace to log me in to manage my insurance contract - not the rest
> of "me" that the card stores as well. Did that, logged into their
> website, no need to even create a username/password combo.
> Note that I didn't use the term "client certificate" at all - the system
> does involve PKI, but it's invisible to the user; all he has is a
> hardware token and a PIN.
> Sure: you need the card reader. Joe Sixpack can manage to go to a shop
> and put money on the shelf to get it, I assume - he does that same thing
> when buying a TV. Joe doesn't even have to know or care about how to get
> a "certificate" - he just gets all the stuff piggybacked on his usual
> plastic ID card.
> Banking: These days, TAN lists are going away. Alternatively, several
> approaches come into use:
> a) cell phone transaction numbers: enter transaction details on website,
> website generates a TAN for this very transaction, sends it along with
> the input it received from you to your (pre-registered) cell phone, you
> enter the number from the cell phone into the website. - A second,
> independent channel makes sure that even if the PC's comms channel is
> compromised, harm is prevented.
> b) offline generated transaction numbers. You get a hardware device,
> branded to your bank account (provisioned secrets). Its only interface
> to the outside world is a black&white camera to read a bar code; and a
> display to show a resulting TAN. Workflow is: you enter your transaction
> details on the web site, they generate $SOMEDATA from it (which includes
> the transaction details). $SOMEDATA is signalled to the hardware device
> via barcode scan, which uses it to generate a TAN based on the
> pre-provisioned secrets and $SOMEDATA. Bank does the same computation,
> TANs must match. Again, a second channel comes to the rescue even if the
> PC is compromised.
> c) HBCI - Home Banking Computer Interface. There is no browser at
> all(!). An application uses the HBCI API to talk to bank servers. Client
> authenticates with a smart card to be put into a card reader. All crypto
> again happens on the card reader. Joe sixpack gets the smart card+PIN by
> checking a box on his bank acocunt application and doesn't need to know
> anything more.
> None of these use Client Certificates in a browser. All of them survive
> if the PC is malware-infested. But yes, there are still attacks on these
> - they are not the cure-all.
> Greetings,
> Stefan Winter
> [1] There are also readers without a keyboard. If you use these, too bad
> for you, because then your infested PC will log your PIN and so on.
> Because of that, the system got quite some beating when introduced.
> _______________________________________________
> TLS mailing list