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

Optional features get marketed, but that doesn't make it any more accurate to claim that they are mandatory.

Many sites (and users) find it valuable to be able to connect to FIDO authenticator implementations outside the browser for a variety of reasons (key portability, hardware key protection, multi-factor authentication affordances) but it can be implemented completely inside the browser, just without these bells and whistles.  This is no different from say, the ability to implement client-certificates using a strictly browser-local certificate store vs. a government e-ID smart card with a device-class identifying OID and PIN.  And in that sense <keygen> is, in practice, no less dependent on software functions / entities outside the browser.

If you want a universal solution for key management with no external dependencies, there is WebCrypto, which combines quite nicely with PKI.js for certificate issuance.  As soon as you need more than that, you're talking about "multiple entities".

From: "SULLIVAN, BRYAN L" <bs3131@att.com<mailto:bs3131@att.com>>
Date: Friday, September 4, 2015 at 5:04 PM
To: Bradley Hill <hillbrad@fb.com<mailto:hillbrad@fb.com>>, Harry Halpin <hhalpin@ibiblio.org<mailto:hhalpin@ibiblio.org>>, Tim Berners-Lee <timbl@w3.org<mailto:timbl@w3.org>>
Cc: "www-tag@w3.org<mailto:www-tag@w3.org>" <www-tag@w3.org<mailto:www-tag@w3.org>>, daniel Appelquist <appelquist@gmail.com<mailto:appelquist@gmail.com>>, "Linss, Peter" <peter.linss@hp.com<mailto:peter.linss@hp.com>>, Wendy Setzer <wendy@seltzer.org<mailto:wendy@seltzer.org>>
Subject: RE: Agenda: <keygen> being destroyed when we need it

By “multiple entities” I mean software functions outside the browser, not third parties (as in sites or OAuth providers etc), although those browser-external software functions are key AFAIK to the value proposition of FIDO’s UAF and U2F selling-points. Focusing only on the over-the-wire protocol, with device metadata (I guess this means fingerprinting source data), may provide some standalone value under FIDO but that is not (again, AFAICT) how the user experience of FIDO is primarily marketed.

Thanks,
Bryan Sullivan | AT&T

From: Brad Hill [mailto:hillbrad@fb.com]
Sent: Friday, September 04, 2015 10:12 AM
To: SULLIVAN, BRYAN L; Harry Halpin; Tim Berners-Lee
Cc: www-tag@w3.org<mailto:www-tag@w3.org>; daniel Appelquist; Linss, Peter; Wendy Setzer
Subject: Re: Agenda: <keygen> being destroyed when we need it

This is not true.  FIDO is origin-bound and point-to-point.  There are no third parties required – much less so than certificates in the general case.  I like to say that FIDO is "PKI without the I".

Biometrics, etc. are completely abstracted away from the on-the-wire protocol.  There is an ability with FIDO to provide device metadata, and to attest that metadata at key registration time with device-class certificates (shared among all devices of a given type to preserve anonymity) but those are strictly optional parts of the protocols.

Browsers can very easily build a software-only, unattested FIDO authenticator to complement their password managers in just a few hundred lines of code, with absolutely no third parties involved.  I know because I've done it.

-Brad Hill

From: "SULLIVAN, BRYAN L"
Date: Wednesday, September 2, 2015 at 4:03 PM
To: Harry Halpin, Tim Berners-Lee
Cc: "www-tag@w3.org<mailto:www-tag@w3.org>", daniel Appelquist, "Linss, Peter", Wendy Setzer
Subject: RE: Agenda: <keygen> being destroyed when we need it
Resent-From: <www-tag@w3.org<mailto:www-tag@w3.org>>
Resent-Date: Wednesday, September 2, 2015 at 4:04 PM

Harry,

FIDO is not a replacement for keygen. It involves multiple entities including some device-native functions that perform key registration etc using biometrics and other options (even SIM-based trusted UIs). It’s a nice concept and is gaining traction, but does have dependencies on functions outside the browser, thus is not a universal solution for key management.

Keeping the keygen tag and functions fully supported by browsers (as a standalone capability) is a more broadly viable solution, and I would recommend it.

Thanks,
Bryan Sullivan | AT&T

From: Harry Halpin [mailto:hhalpin@ibiblio.org]
Sent: Wednesday, September 02, 2015 3:25 PM
To: Tim Berners-Lee
Cc: www-tag@w3.org<mailto:www-tag@w3.org>; daniel Appelquist; Linss, Peter; Wendy Setzer
Subject: Re: Agenda: <keygen> being destroyed when we need it

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

<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://urldefense.proofpoint.com/v1/url?u=https://groups.google.com/a/chromium.org/forum/%23%21topic/blink-dev/pX5NbX0Xack/discussion&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=fdf52bcd3b6d03066429fa3f57c8099217caebb2b6e09aeb651ffcc867421966>

My response to that is here:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/5CQnw56-BQAJ<https://urldefense.proofpoint.com/v1/url?u=https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/5CQnw56-BQAJ&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=8694bbe9eefc77d0717c1127933688cc676a0eb15502ea504754670e407b51dd>

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


TimBL,

It seems the use-case is for people to authenticate securely to web-sites they trust, with the security being done by key material rather than passwords. There is already a standard for that called "FIDO" (Fast IDentity Online) that W3C is already co-operating with, as shown by our workshop final report here:

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html<https://urldefense.proofpoint.com/v1/url?u=http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=93d006807e80f32d80f4b8e2c2159499fd133c451fb85921b4567df8f60bd75e>
The specs are open and cover both key-based authentication (although it cleanly separates out identity from authentication and follows the same-origin policy) and multi-factor authentication.

https://fidoalliance.org/specifications/overview/<https://urldefense.proofpoint.com/v1/url?u=https://fidoalliance.org/specifications/overview/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=f56d3dff32ced0303265a66e95748af6c209d634125a3540e75511d9e54c8a53>
I know myself, quite a few of W3C Team, and many W3C members are excited by FIDO and, while it is currently being developed in a closed process, the plan is I believe to bring it to an open standards process like IETF and W3C.
If your request is to keep <keygen> *until* FIDO is in browsers, I think that's reasonable, although the user-base of people authenticating with client certificates is quite small. However, it is also reasonable to warn developers that it will be deprecated soon, and that new protocols or products should *not* depend on <keygen>.
There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems. X.509 is also problematic to parse, leading to security issues [2]. While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year.
In terms of your current coding projects that depend on <keygen> and WebID+TLS, I'm sure the larger W3C community would be thrilled to work out solutions for your use-cases based on FIDO - and maybe   OAuth (also not perfect, but possible to be improved to give better privacy/anonymity [3])  -  that use the JOSE specs for key material. This would make the exciting coding projects being done by yourself and others compatible with Web while providing better privacy and security properties that the X.509/TLS stack.
So, perhaps a reasonable compromise is that we can not immediately disable <keygen> until FIDO is implemented in browsers, and then remove it, while warning developers *now.*

    yours,
          harry
[1] https://www.secure-resumption.com/<https://urldefense.proofpoint.com/v1/url?u=https://www.secure-resumption.com/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=e5ebebf286e8712333d9c978acf4a237cbb4504af27525b2f9a4383df7c01156>
[2] https://www.cosic.esat.kuleuven.be/publications/article-1432.pdf<https://urldefense.proofpoint.com/v1/url?u=https://www.cosic.esat.kuleuven.be/publications/article-1432.pdf&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=925ce0283d99e435ff9231c345ddb858857afc63763815f7bf082939fd958186>
[3] http://www.degruyter.com/view/j/popets.2015.2015.issue-2/popets-2015-0022/popets-2015-0022.xml<https://urldefense.proofpoint.com/v1/url?u=http://www.degruyter.com/view/j/popets.2015.2015.issue-2/popets-2015-0022/popets-2015-0022.xml&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=7669a8ceb537c2ffbfb1d47ef73ea98caf4770f112ddb304325af564cb925af2>




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://urldefense.proofpoint.com/v1/url?u=https://html.spec.whatwg.org/multipage/forms.html%23the-keygen-element&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=86ddf874f4dff5faa99369004b2de2a0147d5c60b541b16cd49eaea0e388bdd7>

   [2] https://wiki.mozilla.org/CA:Certificate_Download_Specification<https://urldefense.proofpoint.com/v1/url?u=https://wiki.mozilla.org/CA:Certificate_Download_Specification&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=55b51727764159be1ca900de436ac8bd6fbbcc0122436d5bae3720c46c5fb5b6>

   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://urldefense.proofpoint.com/v1/url?u=https://connect.microsoft.com/IE/feedback/details/793734/ie11-feature-request-support-for-keygen&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=b466d3bd760f7096f2809e083812ffd070245750e8acfcb3696bb700ee48bcce>

   [4] https://lists.w3.org/Archives/Public/public-html/2009Sep/0153.html<https://urldefense.proofpoint.com/v1/url?u=https://lists.w3.org/Archives/Public/public-html/2009Sep/0153.html&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=51b75c8069b8a42169fc3e5a530d89cd34f3a8fb51498485abc9a02b0372747f>

   [5] https://blog.whatwg.org/this-week-in-html5-episode-35<https://urldefense.proofpoint.com/v1/url?u=https://blog.whatwg.org/this-week-in-html5-episode-35&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=8df6981ad08d9d51b556935a2b3b362c8b5227de3dab3385bdffc2479d503410>

   [6] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen<https://urldefense.proofpoint.com/v1/url?u=https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=8b56075a0159f382f2a3cf0071e3205ee071fb62cda7fb11d3654e8ca8f79796>

   [7] https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element<https://urldefense.proofpoint.com/v1/url?u=https://html.spec.whatwg.org/multipage/forms.html%23the-keygen-element&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=86ddf874f4dff5faa99369004b2de2a0147d5c60b541b16cd49eaea0e388bdd7>

   [8] https://developer.mozilla.org/en-US/docs/Archive/Mozilla/JavaScript_crypto/generateCRMFRequest<https://urldefense.proofpoint.com/v1/url?u=https://developer.mozilla.org/en-US/docs/Archive/Mozilla/JavaScript_crypto/generateCRMFRequest&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=d7be5ca1cbdd4959d99626205a28db4b86477cf0d9241a244da57e0d3675897b>

   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.


   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://urldefense.proofpoint.com/v1/url?u=https://www.chromestatus.com/metrics/feature/popularity%23HTMLKeygenElement&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=b031ad771067a867707497ddda5e602a3a023879617fa5f38c29dcfe8fa669e6>

   [10] https://bugzilla.mozilla.org/show_bug.cgi?id=1024871<https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.mozilla.org/show_bug.cgi?id%3D1024871&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=f68490c8da65457bf827b9ecb8b93e3a505ce4a2ee7d39e4d3c7c314e225d199>

   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://urldefense.proofpoint.com/v1/url?u=https://developer.chrome.com/extensions/enterprise_platformKeys&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=d362ed4706fe977afc0d86005122235074745f2f2adb8424b745107a53b5805f>

   [12] https://fidoalliance.org/<https://urldefense.proofpoint.com/v1/url?u=https://fidoalliance.org/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=f73b855e9e9ec07eec36c1a29ac8fb227f249ecc5936aaf70c16935da74aaa2d>

   [12] https://fidoalliance.org/google-launches-security-key-worlds-first-deployment-of-fast-identity-online-universal-second-factor-fido-u2f-authentication/<https://urldefense.proofpoint.com/v1/url?u=https://fidoalliance.org/google-launches-security-key-worlds-first-deployment-of-fast-identity-online-universal-second-factor-fido-u2f-authentication/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=64731220bf2e28910e61eadb6f1533a77c01e2b093281c18d7e5ff1b70c7e126>

   [14] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729<https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.mozilla.org/show_bug.cgi?id%3D1065729&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=e53fa51e6643644765aa04940a8a99cbccce5345c4909cf5b91d193174af3e6e>


   Usage information from UseCounter

   https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement<https://urldefense.proofpoint.com/v1/url?u=https://www.chromestatus.com/metrics/feature/popularity%23HTMLKeygenElement&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=b031ad771067a867707497ddda5e602a3a023879617fa5f38c29dcfe8fa669e6>


   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://urldefense.proofpoint.com/v1/url?u=https://code.google.com/p/chromium/issues/detail?id%3D514767&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=2a1b5fe03c5060afce240526437e48536d24442dfd73ad9146cb9b78693cbbbf>

   Entry on the feature dashboard

   https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement<https://urldefense.proofpoint.com/v1/url?u=https://www.chromestatus.com/metrics/feature/popularity%23HTMLKeygenElement&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=Y4FZ7LtJW5SZPcv%2B32JL0MtnkeTGoXTQRxQzW4xZRBw%3D%0A&s=b031ad771067a867707497ddda5e602a3a023879617fa5f38c29dcfe8fa669e6>

   Requesting approval to remove too?

   No