W3C home > Mailing lists > Public > www-tag@w3.org > March 2016

Re: What we were using public key authentication for

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Thu, 24 Mar 2016 13:12:16 +0100
Message-ID: <CAKaEYh+3Cjgxj+PiQ-aXYqDOwPA68iSf-QAFS=4caECSeL4+Hw@mail.gmail.com>
To: Graham Leggett <minfrin@sharp.fm>
Cc: Tim Berners-Lee <timbl@w3.org>, GALINDO Virginie <Virginie.Galindo@gemalto.com>, Public TAG List <www-tag@w3.org>
On 24 March 2016 at 12:49, Graham Leggett <minfrin@sharp.fm> wrote:

> On 24 Mar 2016, at 12:08 AM, Tim Berners-Lee <timbl@w3.org> wrote:
>
> > This is the system we have been using for someone to be able to identify
> themselves as the owner of a web page, like a blog.
>
> This is also the system used by my grandmother’s pension fund to secure
> systems internal to her pension fund. It is also the same system used by
> organisations such as the BBC across tens of thousands of people to secure
> their data in transit between layers in their systems. Keygen provides a
> secure vendor neutral and standards compliant way to get a digital
> certificate securely onto a machine.
>
> Sure, my grandmother doesn’t know or care about certificates, but she sure
> cares about her pension fund.
>
> > We have been doing this using client certs, but the UI was unloved, the
> keygen API weird and had bugs, browsers have had a war against client
> certs.  But the system worked!   Until keygen got turned off in Chrome and
> Firefox  a few days ago.
>
> Not only did the system work, the system of client certs is immune to man
> in the middle attacks.
>
> With a certificate on both sides of the connection, if one side is
> compromised by a man in the middle (think hacked CA, mistrusted root,
> whatever), the security on the other side of the connection is still
> intact, and the connection will fail safe. Sure, Eve can pretend to be your
> bank, but Eve cannot pretend to be you, and so any attempt by Eve to try
> insert herself between you and your bank will fail.
>
> Over at Apache httpd we care about existing users, and we go to
> significant lengths to ensure that none of our users are suddenly DoSed by
> changes made. If we want to change something we deprecate the old, and
> ensure that something new exists to replace the old before removing it so
> our users aren’t left suddenly in the lurch. In contrast, Firefox and
> Chrome have arbitrarily ripped the carpet out from users without warning in
> a systematic attempt to remove strong crypto from the browser ecosystem,
> which in contrast to the Apache approach represents a significant lack of
> project maturity and governance.
>
> The browser is seeing the erosion of an important security feature, and we
> should be concerned by this.
>
> > So can we get this functionality using web crypto in the short term?
> >
> > Suppose we
> > 1) generate the keys in a web app using web crypo, store them in ephemal
> strage, and rejenerate them any time the use clears the key storage. Use
> them in a custom HTML form based auth session with the server in which we
> invent our own PK based authentication protocol.
>
> How do I know my browser generated the key, and that the key wasn’t given
> to me by someone else? Without reverse engineering the javascript code I
> was given to run I can’t, and as such web crypto offers no security
> guarantees to the end user.
>
> > 2) genearte the keys using math, possibly web cryto with “exportable”
> keys, and download a .pem file to the user’s desktop.  Get the user to
> click on the .pem and go through the process of installing the cert on
> their site. Hope fingers crossed the browsers don’t just block the use of
> client certs at all!
>
> Again, if I don’t know for sure I generated the key, then there is no
> security for me.
>
> > 3) Switch the while thing over to use openID-connect to connect people
> to some password-protected site?
>
> This relies solely on trust of the PKI. If I compromise any CA you trust,
> I can help myself to your identity at will.
>

Although CA's are used to provide claims about public keys, we ought not
think of public keys in that way.  We should think of public keys as
public.  Meaning they are widely publicized.  The exact method could vary
from time to time, and place to place.  A public key may be publicized on a
web page, it may be in a signed claim, it may be in a certificate, it may
be published on usenet or freenet, or even published in an advert the new
york times.

We should think of the publication of a public key as orthogonal to the
problems that it solves.  Namely it allows a secure conversation between
two parties without having to go through a trusted third party, which is,
among other things, a privacy leak.


>
> Regards,
> Graham
> —
>
>
>
Received on Thursday, 24 March 2016 12:12:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:13 UTC