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

Re: Using client certificates for signing

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Tue, 23 Feb 2016 11:11:17 +0100
Message-ID: <CADEL5zv13kTtrP4MqjtoVcY-ZzcDxRkg2Y0HR3G+2wZSTRReFw@mail.gmail.com>
To: Henry Story <henry.story@gmail.com>
Cc: public-webappsec@w3.org, Mitar <mmitar@gmail.com>
On Feb 23, 2016 8:26 AM, "Henry Story" <henry.story@gmail.com> wrote:
>
>
> > 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
>
>   http://w3ctag.github.io/client-certificates/
>
> I'd suggest reading that for guidance rather than the rumour mill.

That Microsoft has removed support for client certificate enrollment is a
FACT.

>
>
> > 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 10:11:46 UTC

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