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
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
From: dane <dane-boun...@ietf.org> 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.
> 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
dane mailing list