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

Re: Alternative proposal for the form signing using client-certificate

From: Mitar <mmitar@gmail.com>
Date: Fri, 11 Mar 2016 19:33:23 -0800
Message-ID: <CAKLmikMFExf3=TY9HQJMVS1GxQhm6PH_NqipFEh+qMwNfce-0w@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Crispin Cowan <crispin@microsoft.com>, "timeless@gmail.com" <timeless@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi!

On Fri, Mar 11, 2016 at 1:39 AM, Anders Rundgren
<anders.rundgren.net@gmail.com> wrote:
> One of the core issues is that HTTPS client-certificate authentication
> is considered a bad application not only for privacy and UI reasons,
> but for scalability as well.  All new authentication systems (for browsers)
> build on application-level authentication rather than transport-level ditto.

I agree. This is why I am proposing an application-level form element
to use client certificates available in the browser, instead of them
just being available for HTTPS.

> This isn't aligned with the market in general which uses mobile devices
> which are (technically) incompatible with the eID vision.

Market depends on the ecosystem. And ecosystem depends on the standard
features enabled. It is a chicken and egg problem. I would agree that
currently eID has not expanded widely, but this is also because it is
hard for 3rd party services to build upon it.

But I hope that FIDO and everything else will come with working
solutions and that then legislations will pick this up and make it
available to the community. I hope it will sooner than in 10 years.

Or we could have a simple form element which builds on everything
already available in browsers (client-certs, crypto) and we can try
new thins now. With legislations already aligned.

We should also not forget about one other important aspect of digital
signatures: legislators can easier understand it (if they can
understand such concepts at all). You have a form, you digitally sign
it. I can understand that and terminology sounds similar to what I am
used to do in a analog world.

> "Other ways" only means other technical solutions than furnishing signature
> support in browsers.  Some parties have turned to server-signatures which
> is a moderately thrilling idea but that's where we are today.

They are sadly not legally bound. :-(

> Sweden uses a system where you send signature requests to a mobile "App".
> Although slightly inferior, I think this concept is way better than hoping
> on a unified signature standard in browsers.  Why is that?  Well, your
> scheme
> may appear simple on the surface but if you would go into real
> standardization
> you would pretty soon find that consensus would reach zero :-).

Why? There is web crypto standard already. You expose those signing
protocols and this is it.

It would be good enough, because it already covers algorithms
governments use as well.

> Europe's efforts in eID aren't that impressing (been into eID since 20 years
> back); they never succeed creating a standard for cards and middleware.

O yes! And why is that? :-) Because of a chicken and egg problems of
having some standards in browsers. Every country goes and then creates
their own plugins and extensions to make things work. No wonder.

> In my new country France, they don't even have a concept of a citizen ID
> which means that you must manage 5-6 different passwords in order to access
> all e-gov services!

I am sorry for you. :-)

I love that in Slovenia I can send an e-mail and use my certificate
with S/MIME to sign it and it is a legally bound document. I can issue
receipts in the same way. Really cool stuff. And S/MIME is a standard
so it works well. Sadly, we do not yet have anything like that in
browsers.


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m
Received on Saturday, 12 March 2016 03:33:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:18 UTC