Subject: [pkix] X.509 client certificates on Web - Deprecated by Google

From: Anders Rundgren <[email-masked]>
Date: Thu, 3 Sep 2015 06:40:16 +0200

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack/discussion

"While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, and represents an authentication scheme that does not work well for the web. An alternative means for addressing this use case is to employ the work of the FIDO Alliance [12], which has strong positive signals from Microsoft and Google (both in the WG), is already supported via extensions in Chrome [13], with Mozilla evaluating support via similar means [14]. This offers a more meaningful way to offer strong, non-phishable authentication, in a manner that is more privacy preserving, offers a better user experience, better standards support, and more robust security capabilities"

W3C.org spokesmen are now speaking the same language:
https://lists.w3.org/Archives/Public/www-tag/2015Sep/0011.html

"There have been several high-profile attacks on client certificates (see
for example "Triple Hand-shake" [1]) that make client certificates a not
suitable for authentication systems. X.509 is also problematic to parse,
leading to security issues [2]. While FIDO is not perfect (the privacy
community needs to look at the channel ID work too), its definitely best of
breed right now and I think will solve your use-case over the course of the
next year"

-- Anders

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 Sep 2015 11:35:54 +0300

Hi, Anders.

I think at least the title of this message is misleading. Google is not deprecating client certificates. They’re deprecating the keygen attribute in forms (which could be used in enrollment, but there are other ways).

These are very different things.

Yoav

> On Sep 3, 2015, at 7:40 AM, Anders Rundgren <[email-masked]> wrote:
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 3 Sep 2015 13:52:58 +0200

On 2015-09-03 10:35, Yoav Nir wrote:
> Hi, Anders.
>
> I think at least the title of this message is misleading. Google is not
 > deprecating client certificates. They’re deprecating the keygen attribute
 > in forms (which could be used in enrollment, but there are other ways).
>

I have followed these discussions in other contexts but I believe that the subject
line properly reflects the following words by the Google spokesman:

 >> While a use case exists for provisioning TLS client certificates for authentication,
 >> such a use case is inherently user-hostile for usability, and represents an authentication
 >> scheme that does not work well for the web.

A more interesting discussion is, how did we end up here?

IMO, Google have come to a logical conclusion. For example, if you insert an empty
PKI-card in a machine running the leading desktop OS, typically nothing happens!

FIDO U2F tokens OTOH are (or will be) usable as is.  Unlike traditional smart
cards FIDO tokens does not require a unique driver that some obscure third-party
is supposed to supply and maintain over OS/browser generations.

That is, it is not FIDO alliance that won due to a superior concept, but
the USG + MSFT who never managed creating a useful product that also could
work for other people than a handful of rather deep-pocketed governments.

Anders

>> "While a use case exists for provisioning TLS client certificates for authentication,
>> such a use case is inherently user-hostile for usability, and represents an authentication
>>  scheme that does not work well for the web. An alternative means for addressing this use case is to employ the work of the FIDO Alliance [12], which has strong positive signals from Microsoft and Google (both in the WG), is already supported via extensions in Chrome [13], with Mozilla evaluating support via similar means [14]. This offers a more meaningful way to offer strong, non-phishable authentication, in a manner that is more privacy preserving, offers a better user experience, better standards support, and more robust security capabilities"
>>