Re: [TLS] EU cards

"Blumenthal, Uri - 0668 - MITLL" <> Fri, 29 July 2011 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D84AD21F8C53 for <>; Fri, 29 Jul 2011 07:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.148
X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eju0QeAtQZH7 for <>; Fri, 29 Jul 2011 07:59:57 -0700 (PDT)
Received: from (MX2.LL.MIT.EDU []) by (Postfix) with ESMTP id 7D78E21F8C50 for <>; Fri, 29 Jul 2011 07:59:56 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id p6TExmAf021123; Fri, 29 Jul 2011 10:59:48 -0400
From: "Blumenthal, Uri - 0668 - MITLL" <>
To: "''" <>
Date: Fri, 29 Jul 2011 10:59:47 -0400
Thread-Topic: [TLS] EU cards
Thread-Index: AcxNrXeiSHE2rqByQnqiwpdO1GO6xQAUrELR
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-29_05:2011-07-29, 2011-07-29, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=7 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1107290118
Message-Id: <>
Cc: "''" <>
Subject: Re: [TLS] EU cards
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: Fri, 29 Jul 2011 14:59:58 -0000

In general I'd disagree - but you've made an excellent point about innovation on PC being dead (and therefore no chance to properly secure them while keeping 'em usable). US DoD is moving along the "secure 'em" axis, thus making usability suffer (many reasons for that). Thus many bitching end-users (and some of them actually have reasons to). But overall - comparing what CAC were expected to do with what they actually do - I'd call it a success because they _work_, like it or not. (Now OS changes version and fragile middleware quits, some readers aren't supported, etc - overall not a pleasant picture, but the infrastructure is fine and the capabilities are right.)


----- Original Message -----
From: Anders Rundgren []
Sent: Friday, July 29, 2011 01:07 AM
To: Blumenthal, Uri - 0668 - MITLL
Cc: '' <>
Subject: Re: [TLS] EU cards

On 2011-07-28 21:42, Blumenthal, Uri - 0668 - MITLL wrote:
> Anders,
> Where is your data on government cards usage coming from?

various mailing lists such as:

Most of the people hanging out there are in some way working with the EU cards.

> In US a lot (literally millions) of government email and Web access 
> is secured by what you call "government cards".

I guess you refer to PIV and CAC?
There is a fundamental difference between the US and the EU and that
only in the EU there is something called "citizen-cards" or eID.

Citizens are supposed to buy eID for carrying out secure services on
the Internet.  The cost have been high; results have been marginal
for the reasons I listed (and some more...).

Obama's NSTIC is something similar (but still very different) that
will be slightly interesting following although I don't think
their NIST friends really understand the consumer market and
the huge technical issues they will have to deal with.

IMO, the PC platform is dead as a vehicle for innovation; they
might go to phones from the start.  I never understood why
you need a picture on a token for Internet access :-)

Well, "it has always been like that" is probably the [lame] excuse.


> --
> Regards,
> Uri
> ----- Original Message -----
> From: Anders Rundgren []
> Sent: Thursday, July 28, 2011 03:10 PM
> To: Henry Story <>
> Cc: S.tefan Winter <>lu>; Martin Gaedke <>de>; <>
> Subject: Re: [TLS] EU cards
> Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so
> why would the browser vendor bother about how it works?
> Now to the cards: Since
> 1. readers is a non-standard item
> 2. all cards need different middleware
> 3. cannot be fitted with additional certificates
> 4. is generally only trusted by a restricted group
> 5. commercial CAs require certified RP SW, contracts
> this is simply put entirely uninteresting
> The government cards are status projects.  We have issued
> x millions cards.  That they are only used as physical ID-cards
> is something they are slightly less open about...
> Banks in Scandinavia put eID on credit-cards which means that
> every merchant get your SSN as well (if they want).
> As I say all the time: Google and Apple will make all EU cards look
> like they always was: A pile of s--t.
> Anders
> On 2011-07-28 17:07, Henry Story wrote:
>> Hi Peter,
>>  You may want to ask Prof. Martin Gaedke about this. He is working his way through the 
>> EU area on this and should have some good pointers on where these token cards are 
>> going around here. 
>>    Henry
>> On 28 Jul 2011, at 16:45, Peter Gutmann wrote:
>>> Stefan Winter <> writes:
>>>> Banking: These days, TAN lists are going away.
>>> Is there any information on what's being done in countries like France, Italy,
>>> the Netherlands, Spain, ...?  The only place where it's really documented (in
>>> quite some detail) is Germany (with surrounding/similar countries like Austria
>>> and Switzerland using equivalent approaches), but what are other countries in
>>> Europe doing?  There's rather little information *from third parties, not the
>>> vendors* publicly available on how e-banking is done in France, Spain, ...,
>>> the pros and cons, how it deals with new attack types, and so on.
>>>> a) cell phone transaction numbers:
>>> The problem is that mTANs are vulnerable to smartphone malware, as Zeus has
>>> already shown.  It's currently a minor threat, but who knows how far the bad
>>> guys will take it.  On the whole though mTANs are a nice tradeoff, you get to
>>> verify the transaction over an independent channel, and the mTAN is a
>>> cryptographic hash over the transaction data so if a MITB tries to modify what
>>> the browser sends it gets detected.
>>> Peter.
>>> _______________________________________________
>>> TLS mailing list
>> Social Web Architect
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list
> _______________________________________________
> TLS mailing list