W3C home > Mailing lists > Public > public-rww@w3.org > August 2015

Re: (Pre-)Intent to Deprecate: <keygen> element and application/x-x509-*-cert MIME handling

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Sat, 1 Aug 2015 13:47:27 +0200
To: Henry Story <henry.story@co-operating.systems>, Carvalho Melvin <melvincarvalho@gmail.com>
Cc: Read-Write-Web <public-rww@w3.org>, public-webid <public-webid@w3.org>
Message-ID: <55BCB1CF.3050700@gmail.com>
On 2015-08-01 11:08, Henry Story wrote:
> As a pointer for future reference the full thread is here:
>
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack/discussion <https://groups.google.com/a/chromium.org/forum/#%21topic/blink-dev/pX5NbX0Xack/discussion>
>
> Ryan Sleevi keeps arguing that he has fundamental arguments against keygen and client certs.

Ryan like most other high priests of the Web are on a crusade against the concept of sharing an identity or key with multiple sites.  This was one of the core motivations behind FIDO and U2F which effectively makes this impossible unless you rather use the key with an IdP which in turn [typically] provides the same identity to every RP.

IMO, these guys are way off in their analysis of how the Web works for "ordinary people" who have no issues using Google and Facebook as IdPs to any number of independent services which effectively supports the same tracking facility as X.509 certificates PLUS the fact that they also know where you are going!

That essentially every meaningful service you can think of also requires an e-mail address which is a static, personal, and long-lived Globally Unique IDentifier (GUID), is a fact that the mentioned lot tends to "forget" since it shatters their vision into confetti.

A problem with U2F is that it is developed in a closed environment so we currently know nothing about the 2.0 version that is supposed to be shipping this fall.  Maybe it offers the support needed to drop X.509?  I would be surprised if it does but of course that's just my gut feeling.

Anders

> But for each of the arguments presented it is easy to find answer often a UI interface improvement
> that would solve the stated problems. Other problems are handwaved at and I am still waiting for clarification.
>
> There are pointers to other technologies that would be better aparently, but it is suspicious that
> they should want to remove a working one for yet to be tested ones, which makes it look more
> like a political/business move than a technical one: removing a problematic competitor is often
> easier than proving oneself.
>
> Hopefully the discussion will help clarify some things.
>
> Henry
>
>> On 30 Jul 2015, at 18:01, Melvin Carvalho <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>>
>> FYI: Google / Ryan Sleevi's comments on WebID
>>
>> ---------- Forwarded message ----------
>> From: *Ryan Sleevi* <rsleevi@chromium.org <mailto:rsleevi@chromium.org>>
>> Date: 30 July 2015 at 17:53
>> Subject: Re: (Pre-)Intent to Deprecate: <keygen> element and application/x-x509-*-cert MIME handling
>> To: Melvin Carvalho <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>>
>> Cc: blink-dev <blink-dev@chromium.org <mailto:blink-dev@chromium.org>>
>>
>>
>>
>> On Jul 30, 2015 7:42 AM, <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>> >
>>
>> >
>> > -1 KEYGEN is in use.
>> >
>> > This move will be severely detrimental several grass roots communities, such as the WebID community.
>> >
>> > [1] https://www.w3.org/community/webid/participants
>> >
>>
>> This comment doesn't really address any of the technical concerns raised. WebID has repeatedly demonstrated a willingness to appropriate ill-suited technology, and has readily acknowledged that no browser implements the desired functionality for WebID to be successful.
>>
>> WebID is still nascent, and readily admits it won't work with Edge. An alternative would be for WebID to proceed with standards that are actually widely used and have a viable chance at being usable - such as WebCrypto.
>>
>> But it seems odd to hold a feature that was never fit to purpose nor working as desired hostage for experimental activity in a CG.
>>
>>
>
Received on Saturday, 1 August 2015 11:48:05 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 1 August 2015 11:48:05 UTC