W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2016

Re: Using client certificates for signing

From: Henry Story <henry.story@gmail.com>
Date: Tue, 23 Feb 2016 07:26:12 +0000
Cc: Mitar <mmitar@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-Id: <7E238C69-17E1-438E-9129-8A5D5F1AF83C@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>

> On 23 Feb 2016, at 04:45, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> Hi Mitar,
> The W3C (or rather Google and Facebook), have unilaterally decided that the
> eID use case (using a single certificate/key to login and sign to unrelated
> parties/domains) is in conflict with the Web security and privacy model and
> are therefore removing support for this feature step by step.
> The first step was removing the support for plugins. The "<keygen>" tag you
> mention is also considered "evil" and is now about to go:
> https://lists.w3.org/Archives/Public/www-tag/2015Sep/0000.html
> Microsoft have already removed their counterpart from the "Edge" browser.

Microsoft are also behind the W3C TAG (Techncial Architecture Group) finding
on client certificates


I'd suggest reading that for guidance rather than the rumour mill.

> Nowadays the browser vendors recommend using FIDO alliance schemes which were
> explicitly designed for the Web: https://fidoalliance.org/
> However, the eID use-case is alive and kicking, it has only moved to the "App" world
> where it (through the use of rather slimy OOB-schemes) continues to provide valuable
> services to millions of users on a daily basis.  In the latest incarnation of the
> Swedish "Mobile BankID", you cannot only login (and sign) to hordes of public sector
> e-services and a bunch of banks, but transfer money to 40-50% of the population
> using a phone number only. All powered by a single mobile eID.
> We have probably not yet got the entire story; when Google needed a way to extend
> the Web in Android they just added it and without any opposition whatsoever so it
> is provably doable :-)
> https://github.com/w3c/webpayments/issues/42#issuecomment-166705416
> Anders
> On 2016-02-23 00:27, Mitar wrote:
>> Hi!
>> I tried some more information about the lack of APIs to access client
>> certificates from the web applications, and found this position paper:
>> https://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/Using_the_W3C_WebCrypto_API_for_Document_Signing.html
>> But not much more. I wonder why there is no API to really do something
>> useful with those certificates inside web applications. There is
>> <keygen> HTML tag to generate it, but there is no <keysign> for
>> example that one could sign the content of the form.
>> I know that some European countries use state provided certificates to
>> their citizens, but the lack of APIs in browsers require them to use
>> special extensions, which complicate their use even more. Is it
>> possible that the lack of relevant APIs is because client side
>> certificates have not found mainstream use in industry?
>> What should be done to move this further? Maybe create <keysign> tag,
>> maybe allow getting key for signing to be used by web crypto API?
>> Mitar
Received on Tuesday, 23 February 2016 07:26:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC