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

Re: Using client certificates for signing

From: Mitar <mmitar@gmail.com>
Date: Wed, 24 Feb 2016 00:25:47 -0800
Message-ID: <CAKLmikNK+WyDWSQjS7qjtMt_tNHRdPkMvpRO9nQH9RSmdM=5aQ@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Crispin Cowan <crispin@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi!

On Tue, Feb 23, 2016 at 11:36 PM, Anders Rundgren
<anders.rundgren.net@gmail.com> wrote:
> Yes, but that requires that the signature application is an intrinsic
> part of the browser.

True. But that might be OK? Having it be part of browser means that it
can be part of the trusted UI.

>  I have devoted quite a bit of time developing such
> a scheme (http://webpki.org/papers/wasp/wasp-tutorial.pdf), but I have
> (for any number of reasons) given up on that idea.

Hm, interesting, but it seems a bit complicated. Wouldn't simply
signature of data of the form submission (like HTTP POST) be enough?

> Right now we are in a situation where the entire eID concept is questioned.
> After witnessing the vendor having an 80%+ market share on desktop/laptop
> OSes remove support for their counterpart to <keygen>, traditional eID on
> the Web appears to be pretty dead.

But isn't this chicken and egg problem? Because of incomplete browser
support those features were not much used. People had to develop their
own workarounds, browser extensions, Java applets and so on.

> I'm personally very skeptical about solutions that build on non-sanctioned
> methods
> because they will most likely cease to work on certain platforms and
> browsers.

Yes. :-(


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m
Received on Wednesday, 24 February 2016 08:26:17 UTC

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