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

A few additional details below.

> On 1 Sep 2015, at 16:08, Tim Berners-Lee <timbl@w3.org> 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.

I opened an issue on the WHATWG's recently moved to (and therefore perhaps not yet widely known) github repository yesterday after the <keygen> deprecation commit had been pushed to master.

   https://github.com/whatwg/html/issues/67 <https://github.com/whatwg/html/issues/67>

This issue was then closed within a few hours ( citing the fact that the commit had already been pushed)

I then sent a mail to the whatwg mailing list, where this issue had clearly not been discussed nor brought up:
https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Sep/0003.html <https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Sep/0003.html>

This recent discussion was split over now at least 5 different lists. Similar arguments come up in these different lists, requiring repeatedly similar points to be made. In many cases on questioning an argument I vaguely pointed to debates that happend on other lists. All in all the key arguments are very hard to come by. One gets a strong feeling of decisions being made by secret evidence.  This is very similar to when reference to not yet deployed technology from other standards organisation ( eg. FIDO ) is made to support the argument to retract keygen. Finally the criteria of security vary widely. Hypothetical security issues of keygen are put forward by the same people who then feel no problem with the fact that current JS APIs produce keys that have to be stored in the browser local storage and are then made available to all other applications of the same origin.

My suggestion is that a full list of problems and advantages of keygen and indeed the wider security space needs to be drawn up. These have to be evaluated against various often conflicting criteria. ( Eg. is centralisation less problematic than privacy? ) Such a detailed map could then be used to improve either keygen, an equivalent JS api, or even at some point help comparison with other technologies such as FIDO.

It is only by going through these problems in detail and in the open that there is any chance of finding out what is broken and what needs improving in the web security space.

Listening to actual users of the technology would also be helpful.

( Btw. is there an HTML WG too I should post this to? )

> 
> <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.
> 
> Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.
> 
> 
> It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.
> 
> Keygen is not therefore something which you can just code in Javascript. 
> 
> The original July 28  announcement from the Chrome team is here:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack/discussion <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack/discussion>
> 
> My response to that is here: 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/5CQnw56-BQAJ <https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/5CQnw56-BQAJ>
> 
> I attached an attempt to recreate the indentation of text/response which got messed up in some versions.
> 
> Let's put this on the TAG agenda.
> 
> Tim
> 
> 
> 
> On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:
> 
>>    Summary
>> 
>>    This is an intent to deprecate, with the goal of eventually removing, support for the <keygen> element [1], along with support for special handling for the application/x-x509-user-cert [2].
>> 
>> 
>>    This is a pre-intent, to see if there are any show-stopping use cases or compatibility risks that have hitherto been unconsidered.
>> 
>> 
> Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.
> 
>> 
>>    [1] https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element <https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element>
>> 
>>    [2] https://wiki.mozilla.org/CA:Certificate_Download_Specification <https://wiki.mozilla.org/CA:Certificate_Download_Specification>
>> 
>>    Motivation
>> 
>>    History: <keygen> was an early development by Mozilla to explore certificate provisioning. Originally Firefox exclusive, it was adopted by several mobile platforms (notably, Nokia and Blackberry), along with support for the certificate installation mime-types. During the First Browser Wars, Microsoft provided an alternative, via ActiveX, called CertEnroll/XEnroll. When iOS appeared on the scene, <keygen> got a boost, as being the initial way to do certificate provisioning, and along with it brought support into Safari. It was then retro-spec'd into the HTML spec.
>> 
>> 
>>    Issues: There are a number of issues with <keygen> today that make it a very incompatible part of the Web Platform.
>> 
>>    1) Microsoft IE (and now Edge) have never supported the <keygen> tag, so its cross-browser applicability is suspect. [3] Microsoft has made it clear, in no uncertain terms, they don't desire to support Keygen [4][5] 
>> 
>> 
> Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.
> 
> 
>    2) <keygen> is unique in HTML (Javascript or otherwise) in that by design, it offers a way to persistently modify the users' operating system, by virtue of inserting keys into the keystore that affect all other applications (Safari, Chrome, Firefox when using a smart card) or all other origins (Firefox, iOS, both which use a per-application keystore)
> 
> 
> If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until
> 
>> 
>>    3) <keygen> itself is not implemented consistently across platforms, nor spec'd consistently. For example, Firefox ships with a number of extensions not implemented by any other browser (compare [6] to [7])
>> 
>> 
> A solution would be then to extend the standrad in future versions and code compatibly to that.
> 
> 
>>    4) <keygen> itself is problematically and incompatibly insecure - requiring the use of MD5 in a signing algorithm as part of the SPKAC generated. This can't easily be changed w/o breaking compatibility with UAs.
>> 
>> 
> Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time
> 
> If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?
> 
> 
> 
>>    5) <keygen> just generates keys, and relies on application/x-x509-*-cert to install certificates. This MIME handling, unspecified but implemented by major browsers, represents yet-another-way for a website to make persistent modifications to the user system.
>> 
> 
> There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
> Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.
> 
> If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly
> 
>>    6) Mozilla (then Netscape) quickly realized that <keygen> was inadequate back in the early 2000s, and replaced it with window.crypto.generateCRMFRequest [8], to compete with the CertEnroll/XEnroll flexibility, but recently removed support due to being Firefox only. This highlights that even at the time of introduction, <keygen> was inadequate for purpose.
>> 
>> 
>>    [3] https://connect.microsoft.com/IE/feedback/details/793734/ie11-feature-request-support-for-keygen <https://connect.microsoft.com/IE/feedback/details/793734/ie11-feature-request-support-for-keygen>
>> 
>>    [4] https://lists.w3.org/Archives/Public/public-html/2009Sep/0153.html <https://lists.w3.org/Archives/Public/public-html/2009Sep/0153.html>
>> 
>>    [5] https://blog.whatwg.org/this-week-in-html5-episode-35 <https://blog.whatwg.org/this-week-in-html5-episode-35>
>> 
>>    [6] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen>
>> 
>>    [7] https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element <https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element>
>> 
>>    [8] https://developer.mozilla.org/en-US/docs/Archive/Mozilla/JavaScript_crypto/generateCRMFRequest <https://developer.mozilla.org/en-US/docs/Archive/Mozilla/JavaScript_crypto/generateCRMFRequest>
>> 
>>    Compatibility Risk
>> 
>>    While there is no doubt that <keygen> remains used in the wild, both the use counters [9] and Google's own crawler indicate that it's use is extremely minimal. Given that Mozilla implements a version different than the HTML spec, and given that Microsoft has made it clear they have no desire to implement, the compatibility risk is believed to be low in practice.

But they have similar technology with their XEnroll API
https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx <https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx>

It is easy to create JS that either uses keygen or Xenroll depending on the browser. Certainly not ideal,
but that's the world we live in.

>> 
>> 
>>    Mozilla is also exploring whether or not to remove support for the application/x-x509-*-cert types [10], but has not yet (to my knowledge) discussed <keygen> support - either aligning with the (much more limited) spec, extending the spec with the Mozilla-specific extensions, or removing support entirely.
>> 
>> 
>>    On the application/x-x509-*-cert support, there is a wide gap of interoperability. Chrome does not support multiple certificates, but Firefox does. Firefox will further reorder certificates that are inconsistent with what was specified, offering a non-standard behaviour. Chrome does not support application/x-x509-ca-cert on Desktop, and on Android, defers to the platform capabilities, which further diverge from Firefox. Both browsers have the underspecified behaviour of requiring the user having a matching key a-priori, except that's not detailed as to how it works. Firefox also handles various mis-encodings (improper DER, DER when it should be base64), which Chrome later implemented, but is not well specified.
>> 
>> 
>> Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.
>> 
>> 
>> 
>> 
>>    [9] https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement <https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement>
>> 
>>    [10] https://bugzilla.mozilla.org/show_bug.cgi?id=1024871 <https://bugzilla.mozilla.org/show_bug.cgi?id=1024871>
>> 
>>    Alternative implementation suggestion for web developers
>> 
>>    The primary use cases for <keygen>, from our investigations, appear to be tied to one of two use cases:
>> 
>>    - Enterprise device management, for which on-device management capabilities (Group Policies, MDM profiles, etc) represent a far more appropriate path. That is, you would not expect a web page to be able to configure a VPN or a users proxy, so too should you not expect a webpage to configure a user's system key store.
>> 
>>    - CA certificate enrollment, for which a variety of alternatives exist (e.g. integrated to the web server, CA specific-tools such as SSLMate or protocols such as Let's Encrypt, etc). Here again, it does not seem reasonable to expect your web browser to configure your native e-mail client (such as for S/MIME)
>> 
>> 
>>    Within the browser space, alternatives exist such as:
>> 
>>    - Use the device's native management capabilities if an enterprise use case. On Windows, this is Group Policy. On iOS/Android, this is the mobile device management suites. On OS X, this is Enterprise settings. On ChromeOS, there is chrome.enterprise.platformKeys [11] for enterprise-managed extensions.
>> 
>>    - Use WebCrypto to implement certificate enrollment, then deliver the certificate and (exported) private key in an appropriate format for the platform (such as PKCS#7) and allow the native OS UI to guide users through installation of certificates and keys.
>> 
> 
> The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.
> 
> 
> 
> 
>> 
>>    On some level, this removal will remove support for arbitrarily adding keys to the users' device-wide store, which is an intentional, by-design behavior.
>> 
>> 
> I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.
> 
>>    While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 
>> 
>> 
> What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,
> 
> 
> 
>> 
>>    and represents an authentication scheme that does not work well for the web. 
>> 
> 
> Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?
> 
> 
> 
>>    An alternative means for addressing this use case is to employ the work of the FIDO Alliance [12], which has strong positive signals from Microsoft and Google (both in the WG), is already supported via extensions in Chrome [13], with Mozilla evaluating support via similar means [14]. This offers a more meaningful way to offer strong, non-phishable authentication, in a manner that is more privacy preserving, offers a better user experience, better standards support, and more robust security capabilities.
>> 
> 
> Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.
> 
> In the mean time, please fix bugs in client certs which are just a pain.
> 
> - Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
> - Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.
> 
> - In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)
> 
> So don't abandon <keygen>, fix it.
> 
> And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  
> 
> In the meantime please support keygen and improve client cert handling. 
> 
> timbl
> 
> 
> 
> 
> 
> 
> 
> 
> 
>    [11] https://developer.chrome.com/extensions/enterprise_platformKeys <https://developer.chrome.com/extensions/enterprise_platformKeys>
> 
>    [12] https://fidoalliance.org/ <https://fidoalliance.org/>
> 
>    [12] https://fidoalliance.org/google-launches-security-key-worlds-first-deployment-of-fast-identity-online-universal-second-factor-fido-u2f-authentication/ <https://fidoalliance.org/google-launches-security-key-worlds-first-deployment-of-fast-identity-online-universal-second-factor-fido-u2f-authentication/>
> 
>    [14] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729 <https://bugzilla.mozilla.org/show_bug.cgi?id=1065729>
> 
> 
>    Usage information from UseCounter
> 
>    https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement <https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement>
> 
> 
>    Based on data seen from Google crawler (unfortunately, not public), the number of sites believed to be affected is comically low. 
> 
> 
>    OWP launch tracking bug
> 
>    https://code.google.com/p/chromium/issues/detail?id=514767 <https://code.google.com/p/chromium/issues/detail?id=514767>
> 
>    Entry on the feature dashboard
> 
>    https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement <https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement>
> 
>    Requesting approval to remove too?
> 
>    No
> 
>