Removing <keygen>

[domenic]

We previously deprecated keygen in 1b43806. It was never implemented in Edge, and Chrome is moving to remove all key types and thus all UI, per blink-dev.

Last time this was discussed I was told Firefox was also interested in deprecating and removing. @smaug----, @bzbarsky, any thoughts there? While we're at it, any thoughts from WebKit, @rniwa @cdumez?

We should discuss whether we want to remove support for keygen entirely, similar to what is slated for <applet> in #1399. This would mean:

• No longer submitting it in the form data set at all, instead of submitting an empty string
• Removing the HTMLKeygenElement API (keygen elements would become HTMLUnknownElement)
• Removing it from the various form-associated things, so e.g. it would not show up in form.elements
• (Optional, but see below) Removing parser support for it

We have tentative support for doing this from @sleevi on the blink-dev ("that would make logical sense"), and of course Edge does not implement support at all---except for parsing, it appears. See http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4685. Note that Firefox's current parsing is bizarre; it transforms it into a <select _moz-type="mozilla-keygen"> element. So maybe there is some flexibility there. But in the past (e.g. for applet) we've decided to not change the parser when removing elements.

What I'd like to get out of this thread is:

• Are more browsers than Chrome and Edge interested in neutering keygen's functionality by making it never support any key types?
• Are more browsers than Chrome and Edge interested in removing keygen entirely?

[sleevi]

Summoning @rlbmoz on support at Moz

[sleevi]

Actually, @mozkeeler may be a better summon :)

[mozkeeler]

As far as I know, we (members of various security teams at Mozilla) haven't discussed this as a group recently, but the last I heard, we were interested in removing keygen. Whether or not it's best to remove it by removing its functionality or by removing it entirely is probably something for the DOM/content team (I imagine there might be compatibility concerns there, but since we're talking about making it functionally inoperable, maybe it doesn't matter).

[bzbarsky]

My only thought is that I know for a fact keygen is in use in the wild (for example, MIT uses it to generate user certificates for students so they can get access to things like course registration, grades, etc).

So even if there were interest in removing it, we would probably need to communicate the removal quite widely and give people time to switch to whatever they should be doing instead.

[bzbarsky]

@mozkeeler Note that I just discovered that MIT uses a desktop app that munges the OS certificate store to do the user cert generation they want for Edge users. This would obviously not work for Firefox, which doesn't use the OS certificate store...

[bifurcation]

@bzbarsky I hope you're not suggesting that MIT is a sufficient population to keep the feature alive :) They have enough smart folks around that they should be able to figure out an alternative solution.

We've been talking about this for ages, and there's been no mass protest so far. So I'm A-OK with proceeding with removal, shouting it from the rooftops, and if there's outcry in response, we can pull back.

[bzbarsky]

I'm suggesting that for the specific case of Firefox removing the functionality would break things in the MIT case, while for other browsers that's not the case. I can't speak to the existence of other cases like that, and I'm not saying the removal we should not do the removal. I'm saying we need to communicate it widely and with plenty of lead time for people to deal. Which we certainly haven't done so far.

should be able to figure out an alternative solution

Sure, they'll just force their users to use a different browsers, like any other enterprise setup. ;)

[bifurcation]

should be able to figure out an alternative solution

Sure, they'll just force their users to use a different browsers, like any other enterprise setup. ;)

Unless they're relying on smart cards (in which case God help them), there are nice cross-browser JS solutions that provide the same functionality with only marginally less smooth UX.

[sleevi]

@domenic I want to make sure, but it seems implied with moving to HTMLUnknownElement is that it will be able to have a shadow root attached to it, right? (I simply noticed there were Blink tests asserting no shadow roots for elements with dynamic shadow roots, and confirming that it'd be expected to no longer apply)

[domenic]

@sleevi no, per https://dom.spec.whatwg.org/#dom-element-attachshadow attachShadow does not allow keygen.

[domenic]

@sleevi seems to have removed keygen at https://chromium.googlesource.com/chromium/src/+/5d916f6c6b47472770e03cb483f06a18ca79a0c2. Although he's not 100% sure it will stick, I think this is enough of a sign that we should remove it from the spec. I'll try to work on it today-ish.