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

Anders Rundgren <anders.rundgren.net@gmail.com> Thu, 03 September 2015 11:53 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D0B1A90AC for <pkix@ietfa.amsl.com>; Thu, 3 Sep 2015 04:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggIiF-REgSCV for <pkix@ietfa.amsl.com>; Thu, 3 Sep 2015 04:53:02 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F0B1B2AA7 for <pkix@ietf.org>; Thu, 3 Sep 2015 04:53:01 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so5237900wic.1 for <pkix@ietf.org>; Thu, 03 Sep 2015 04:53:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=NMgmzfEDGyZRZzFB8y0dZsE+Tjl2DuCvgXfnDVmnkhU=; b=IpnKTTh4KWmVym/wdegvi/ykHEJK871QqyXpmRql3N+bDvp2vwdyTwj8/v9qR0v2OJ 1MbU3GkXScr9/PbMyRu9lW/3kpvNSAswWNBjXbxIiwqKx6u+PVi89OLygBRhlCy56Tla QP11d1GAKTNocsncciLiTz/Dyl1JY9am0tRYz1nghoxp9MGoNHZeKrDrGDuwau4xeON4 9NIFbtsDqKn9VrNZpxrJd+H/rDhJRyOBA7MGltoqMaVu13nRjp6yQTlYatwGJCIOtOy1 hkYT4W/hDSyQT/4FiA2HnpBc5xI1Ir/LilxlWUM8fa71Cz+wUHcCnJ8Ap8DXNwtGrg2S jRrw==
X-Received: by 10.194.174.201 with SMTP id bu9mr55545864wjc.73.1441281180422; Thu, 03 Sep 2015 04:53:00 -0700 (PDT)
Received: from [192.168.1.79] (240.196.130.77.rev.sfr.net. [77.130.196.240]) by smtp.googlemail.com with ESMTPSA id p5sm8626267wiy.17.2015.09.03.04.52.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Sep 2015 04:52:59 -0700 (PDT)
To: Yoav Nir <ynir.ietf@gmail.com>
References: <55E7CF30.9000006@gmail.com> <867FF7DA-C849-4535-A28A-14D475656A65@gmail.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <55E8349A.1050502@gmail.com>
Date: Thu, 3 Sep 2015 13:52:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <867FF7DA-C849-4535-A28A-14D475656A65@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/gJsED7126e1kNQ9mGqHUKpoPRo8>
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] X.509 client certificates on Web - Deprecated by Google
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2015 11:53:04 -0000

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).
>
> These are very different things.

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

>
> Yoav
>
>> On Sep 3, 2015, at 7:40 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>>
>> 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
>>
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>