Ilari & Rene,

Certificate-based smart cards are widely used within the US Government. The 
Department of Defense has millions of it's so-called CACs (Common Access Cards) 
in use, and they are used by most DoD employees on a daily basis to access 
information systems (logical access). Other federal agencies have been less 
successful, but still somewhat successful, with the deployment of the PIV 
(Personal Identity Verification) cards for logical access.  It is very common 
for federal agencies to purchase laptops that have slots for smart cards.

The primary advantage of the CAC and PIV cards is that they provide both 
physical access and logical access. For physical access, the cards have 
embedded proximity chips. For logical access, the advantage is that they free 
relying parties from both identity and password management. If a card is lost, 
the employee can get a new card without having to change a single password. 
They also significantly ease the usability burden, as the employee need only 
remember a 6 digit PIN.

I have an article coming out in a few weeks that looks in depth at the CAC and 
PIV deployment.  When it is published, I will post a link here.

Ilari is correct in stating that the use of smartcards requires the deployment 
of a card-reading infrastructure. The growing use of smartcards for credit 
cards might result in the deployment of some credit card readers in the home, 
which could also be used for certificate-containing smartcards. Another 
promising form factor are USB tokens that combine a smartcard chip and a 
smartcard reader.

I believe that one way to move forward in providing strong logical 
authentication is systems that allow people to use the chips in their credit 
cards as an identity root. Another way to move forward is for universities and 
businesses to adopt multi-mode cards for their identification cards. With the 
cost of smart card readers plummeting (they cost less than $15 now retail, and 
the actual parts cost is substantially less), the fact that smartcards provide 
both high levels of usability and security should be attractive to many 

Simson Garfinkel

From: dane <> on behalf of Ilari Liusvaara 
Sent: Saturday, September 17, 2016 12:13 PM
To: Rene 'Renne' Bartsch, B.Sc. Informatics
Cc: IETF DANE Mailinglist
Subject: Re: [dane] draft-ietf-dane-smime-12: TLS client-authentication

On Sat, Sep 17, 2016 at 05:37:12PM +0200, Rene 'Renne' Bartsch, B.Sc. 
Informatics wrote:
> Hi,
> everyone knows the problem:
> We have dozens or hundreds of services to login and every service wants
> a user-name and a password. Most users reuse their passwords and a lot
> of services do not protect the passwords securely (no hashing, salting,
> etc.). If a service is hacked or malicious, the perpetrator can be quite
> sure to be able to reuse the credentials at other services. Not to
> mention passwords like 12345.
> In TLS operation, a user can be authenticated with a client-certificate.
> The password is neither transmitted over the wire nor to the
> service-provider. There is only one single password for the
> client-certificate instead of multiple passwords for multiple services.

> So I suggest to add this case to the application description in section
> 6 of draft-ietf-dane-smime-12 or a successor/errata. (Sorry, I lost
> track of the current state of SMIMEA).

Unfortunately, client certificates tend to be UX disaster. Things only
get worse if one needs to consider multiple services, as using one key
for multiple services tends to have bad security consequences.

These tend to be the reasons browser vendors are phasing out <keygen>
and client certificate installation, pretty much meaning one has to
have physical smartcard for TLS client certificate authentication.

And such smartcards with the necressary equipment are pretty rare
(I happen to have one) and tend to be built around real-world identity,
which is great for some services, but not-so-great for most.

I have once experimented on what it would take to implement client
certificate authentication in a site, and pretty quickly gave up,
given the horrible UX it had (not to mention technical problems,
even with all the PKI baggage I could short-circuited).


dane mailing list
dane Info Page - Internet Engineering Task 
Your email address: Your name (optional): You may enter a privacy password 
below. This provides only mild security, but should prevent others from messing 
with ...

dane mailing list

Reply via email to