Re: Agenda: <keygen> being destroyed when we need it

On 2 September 2015 at 16:53, Melvin Carvalho <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
> On 2 September 2015 at 14:15, Wendy Seltzer <wseltzer@w3.org <mailto:wseltzer@w3.org?Subject=Re%3A%20Agenda%3A%20%3Ckeygen%3E%20being%20destroyed%20when%20we%20need%20it&In-Reply-To=%3CCAKaEYh%2B8BPP9p%2BqzKK0fjFE5k3hoPX-6oLUTPT_wwRkDpixN8g%40mail.gmail.com%3E&References=%3CCAKaEYh%2B8BPP9p%2BqzKK0fjFE5k3hoPX-6oLUTPT_wwRkDpixN8g%40mail.gmail.com%3E>> wrote:
> 
> > On 09/02/2015 04:06 AM, Melvin Carvalho wrote:
> >> On 1 September 2015 at 16:08, Tim Berners-Lee <timbl@w3.org <mailto:timbl@w3.org?Subject=Re%3A%20Agenda%3A%20%3Ckeygen%3E%20being%20destroyed%20when%20we%20need%20it&In-Reply-To=%3CCAKaEYh%2B8BPP9p%2BqzKK0fjFE5k3hoPX-6oLUTPT_wwRkDpixN8g%40mail.gmail.com%3E&References=%3CCAKaEYh%2B8BPP9p%2BqzKK0fjFE5k3hoPX-6oLUTPT_wwRkDpixN8g%40mail.gmail.com%3E>> wrote:
> >>
> >>> Folks
> >>>
> >>> There is a strong move my Google chrome team followed by Firefox to remove
> >>> the <keygen> tag from HTML5.   This has been done without an issue being
> >>> raised in the WHATWG  or HTMLWG apparently.
> >>>
> >>> <keygen> is important because it allows authentication systems to be build
> >>> in a distributed manner. It allows any Mom and Pop shop place to share
> >>> public keys for people they trust.    For example, MIT uses it to create
> >>> secure relationship with faculty and staff, and I use it for friends and
> >>> family.
> >>>
> >>> Public key asymmetric crypto is generally so much stronger than the
> >>> password-based authentication.  It requires certificate management code
> >>> to be written.
> >>>
> >>
> >> IMHO we need an area of the browser under a user's control
> >
> > That seems like a different, and more interesting requirement than
> > "keygen."
> >
> > Keygen was a poorly designed, inconsistently implemented feature, that
> > many sophisticated users and developers found confusing. If we can
> > instead define what features we want to be able to build, and what they
> > depend on that's not provided by WebCrypto, and think about how we can
> > enable users to access these features without opening themselves up to
> > be phished or tracked, that feels like a more productive avenue for
> > discussion than "bring back keygen".
It would be good to have a well document list of these problems so that 
future designs could make sure they did not re-create them. I have not 
yet found a good evolving document that makes these points clearly. 
This is the problem with removing keygen and other features at this point,
as it is quite likely that a number of diffuse misunderstanding ( not unlikely 
given that we are dealing  with overlap between very different disciplines 
from Cryptography to UserInterface Design and distributed data, betwen Browser 
and Server specialities, political issues such as relations between 
privacy and centralisation) are contributing  to simple answers not being found. 
> >
> 
> Looking at the latest Credential Management spec (Sep 2)
> 
> This kind of functionality looks quite promising in terms of helping to
> replace existing functionality
> 
> https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection <https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection>
> 
> A UI mockup here
> 
> https://w3c.github.io/webappsec/specs/credentialmanagement/mock-chooser.png <https://w3c.github.io/webappsec/specs/credentialmanagement/mock-chooser.png>
> 
> But I dont think it's yet in widespread use.
> 
(1) What is needed is a way for the browser to create a public/private key pair, keep the private protected in the browser in such a way that the private key is never accessible or visible to the JS or in any other way, other than perhaps to specific applications under the users control ( which is usually the job of a keychain ). The UI has to make it clear to the user that this is the case. This is what keygen and MS's certificate enrollment JS API also enables [1].
    Not being browser owners we are are obviously not tied to the exact implementation of keygen - though the declarative nature of keygen is perhaps not such a bad idea as it fits with the TAGs finding on the rule of least power [3].

(2) It should be possible for the server to return a certificate using the public-key part it received to form a 
certificate. Currently this was possible by the server returning a X509 Certificate using the application/x-x509-*-cert
mime type ( the same folks wanting deprecate keygen also want to deprecate this). The browser would then find the matching private key and set the certificate in the users certificate store for later authentication to other web sites.
  X509 is an old standard. We are not tied to that. JS equivalents such as the certificate structure proposed by Mozilla
Persona [2] would also be fine. In my view it should be possible for the web server to return a number of different certificates simultaneously in order to allow for a transition period and innovation in the certificate space.

(3) The certicate and public key should allow the user to authenticate using asymetric public key cryptography to any site that he wishes to. Currently this was done using TLS client authentication - which has its problems. For HTTP 2.0 better mechansims need to be invented - but it looks like some tie into TLS is important for security ( the keyword here seems to be HTTP 2.0 channel binding ). As shown in the credentials management document Melvin just pointed to, this requires a User Interface component, keeping the user in charge of authentication and logout. What is missing in the Credentials Management document therefore is a way to authenticate using certificates based on asymetric public key cryptography. 
Note that client certificate managment does not require large centralised and expensive certificate authorities ( expensive because they become liable for untold number of identities ) but can be done in a web of trust manner as shown for example by the WebID specs [4]

All of this is currently possible using keygen, x509 certificates and TLS client authentication. Of course nothing in this space keeps still, and there is always progress. But one cannot avoid tie into to the chrome if one wants the user to be at least aware of what identity he is using on each origin he is going to and in order for him to be able to recognise a phishing attack. This is why this cannot just be done purely at the JS level without tie into the chrome ( It is good to see that the WebApp Sec group agrees with this ).

(4) It would probably be very useful to provide very limited signing APIs that could use this public key material. Of course this would require more UI design work in the chrome. In the security space the rule of least power [3] is more relevant than ever.


[1] https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx <https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx>
[2] https://github.com/mozilla/id-specs/blob/prod/browserid/index.md <https://github.com/mozilla/id-specs/blob/prod/browserid/index.md>
[3] http://www.w3.org/2001/tag/doc/leastPower.html <http://www.w3.org/2001/tag/doc/leastPower.html>
[4] http://www.w3.org/2005/Incubator/webid/spec/ <http://www.w3.org/2005/Incubator/webid/spec/>
    This does not exclude large providers either btw.


> >
> > --Wendy
> >
> >
> > --
> > Wendy Seltzer -- wseltzer@w3.org <mailto:wseltzer@w3.org?Subject=Re%3A%20Agenda%3A%20%3Ckeygen%3E%20being%20destroyed%20when%20we%20need%20it&In-Reply-To=%3CCAKaEYh%2B8BPP9p%2BqzKK0fjFE5k3hoPX-6oLUTPT_wwRkDpixN8g%40mail.gmail.com%3E&References=%3CCAKaEYh%2B8BPP9p%2BqzKK0fjFE5k3hoPX-6oLUTPT_wwRkDpixN8g%40mail.gmail.com%3E> +1.617.715.4883 (office)
> > Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
> > http://wendy.seltzer.org/ <http://wendy.seltzer.org/>        +1.617.863.0613 (mobile)
> >

Social Web Architect
http://bblfish.net/