1315460 - Remove support for HTML Keygen

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Tim Nguyen :ntim]

Keygen support should be removed for the following reasons:
- Firefox never got proper support for HTML keygen (see bug 101019).

- Using a keygen element in Chrome gives you this warning in the console:
The <keygen> element is deprecated and will be removed in M56, around January 2017. See https://www.chromestatus.com/features/5716060992962560 for more details.

- Most importantly, it's been removed from the HTML spec: https://github.com/w3c/html/issues/43

Comment 1

[:Cykesiopka]

(In reply to Tim Nguyen :ntim (use needinfo?) from comment #0)
> Keygen support should be removed for the following reasons:
> [...]
-  The implementation in PSM to do the actual key generation etc is a horrid mess.

Also wanted to leave an FYI that Bug 1284945 extended telemetry for keygen usage till Firefox 60.
Maybe we can remove earlier than that point, maybe not.

Comment 2

[Darkspirit]

Should be WONTFIX.
Please search for what Tim Berners-Lee said about removing <keygen>. Also WebID depends on it. 

We are using client certificates based on ECDSA secp521r1 to authenticate users to our social network.
Also they can export them for the use with IMAPs/SMTPs/XMPP/OpenVPN.

Also FIDO U2F can't handle real client certificates for our usecases. Even real Smartcards are not supported.

No one cares Edge not supporting keygen. It's a default Windows browser to download an open source browser.

Please only implement something like a popup asking for the right to use keygen per site if a keygen tag is found on the page.

Comment 3

[Darkspirit]

(In reply to Tim Nguyen :ntim (use needinfo?) from comment #0)
> - Most importantly, it's been removed from the HTML spec:
> https://github.com/w3c/html/issues/43

"We will also remove it from the first draft of HTML 5.2, which we expect  
to publish this month. We hope that it is either repaired, which seems  
unlikely, or replaced which seems possible but not certain, in the  
timeframe of HTML 5.2 development."

It won't get really removed until there is a solution for the use of TLS client certificates.
And WebCrypto can't store the keys securely (and they can't be used for TLS).

Comment 4

[Darkspirit]

(In reply to bugzilla from comment #2)
> We are using client certificates based on ECDSA secp521r1 to authenticate
> users to our social network.
> Also they can export them for the use with IMAPs/SMTPs/XMPP/OpenVPN.

Please don't forget this usecase, which is not a DoS like a RSA key generation:
<keygen name="name" challenge="token" keytype="ec" keyparams="secp521r1"/>

Comment 5

[Darkspirit]

Depends on: https://bugzilla.mozilla.org/show_bug.cgi?id=1088063 (please add to "Depends on")

Comment 6

[Domenic Denicola]

We've removed keygen from the specification that Firefox follows (which is not the specification quoted in the OP): https://github.com/whatwg/html/pull/2221 . Note that the parser behavior is retained, but it becomes a HTMLUnknownElement.

Tests for the removal are at https://github.com/w3c/web-platform-tests/pull/4402.

Comment 7

[Jonathan Kingston [:jkt] he/him]

Once this bug closes it should also close: https://bugzilla.mozilla.org/show_bug.cgi?id=101019 We have code comments pointing to this bug that should be removed.

Comment 8

[Jonathan Kingston [:jkt] he/him]

Attachment: bug-1315460_htmlparser.patch

Removal from the html parser.

Comment 9

[Jonathan Kingston [:jkt] he/him]

Attachment: bug-1315460_cpp.patch

Getting errors in: accessible/tests/mochitest/elm/test_HTMLSpec.html after fixing.

Also getting errors when building without: nsKeygenHandler.cpp and nsKeygenHandlerContent.cpp

Comment 10

[Jonathan Kingston [:jkt] he/him]

Attachment: bug-1315460_cpp.patch

Comment 11

[Jonathan Kingston [:jkt] he/him]

Moving Bug 1088063 to See also as it's not a blocker here. The removal has been standardised and a new API to add via JS hasn't been worked on. We should consider elevating the priority of that work perhaps though.

:keeler are you the right person to review the nss component of this work?

I'm going to make sure tests pass and enable the web platform ones too next.

Comment 12

[Jonathan Kingston [:jkt] he/him]

I may as well take this also, however if I am slow in completing please speak to me.

Comment 13

[Jonathan Kingston [:jkt] he/him]

This looks like it will break the Cert-O-Matic page within NSS, is this going to be a big issue? We won't have any workable replacement without the Bug 1088063.

As this hooks into NSS and is a pretty large patch to remove I would like to expedite this pretty quick.

Comment 14

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Code in security/manager/ is part of PSM - I can review that or find a suitable reviewer. I don't think you'll need to change anything in NSS itself for this bug.

Comment 15

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1315460 - Removal of keygen element

Review commit: https://reviewboard.mozilla.org/r/208824/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/208824/

Comment 16

[Franziskus Kiefer [:franziskus]]

As David said, no changes to NSS needed. The tool in question (which is actually a test) isn't built as part of Firefox and I don't think anyone is using it. I might remove it from NSS but that's independent of this bug.

Comment 17

[Markus Schraeder]

We also use productive the keygen and import possibility on firefox... How is the alternative way to do this now, if you realy want to sadly remove this feature?

Comment 18

[Markus Schraeder]

We are using keygen, cause its the only way on firefox to import certificates a way the users is able to: -> Because firefox is not using the certificate store of windows.

Please donnot remove this feature untils there is a other way to access the firefox certificate store without installing a program or using the absurd gui for importing a pks12!

Comment 19

[Jonathan Kingston [:jkt] he/him]

Comment on attachment 8938110 [details]
Bug 1315460 - Removal of keygen element

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/208824/diff/1-2/

Comment 20

[Jonathan Kingston [:jkt] he/him]

There is also a comment in security/manager/ssl/tests/unit/test_sdr_preexisting.js that uses code from KeyGen however I'm not sure if this is worth keeping?

Comment 21

[Dana Keeler (she/her) (use needinfo) [:keeler]]

That file (even the code-in-comments) should be orthogonal to keygen, unless I'm missing something.

Comment 22

[Jonathan Kingston [:jkt] he/him]

Ah yeah I wrote that comment at our work week without checking it, I needed to switch profiles and didn't want to lose what I had to check :P. I have a few tests to check before asking for a review.

Comment 23

[Jonathan Kingston [:jkt] he/him]

Comment on attachment 8938110 [details]
Bug 1315460 - Removal of keygen element

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/208824/diff/2-3/

Comment 24

[Jonathan Kingston [:jkt] he/him]

Comment on attachment 8938110 [details]
Bug 1315460 - Removal of keygen element

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/208824/diff/3-4/

Comment 25

[Markus Schraeder]

As you can read on 

https://github.com/w3c/webauthn/issues/1027

the webautn is NOT a replacement for client certification or the authentication of users.

You always need to buy hardware to be able to use webauthn, a hardware free implementation is missing.

Please do not stop supporting keygen until webauthn has the possibility to use public keys without any hardware given!

Comment 26

[Markus Schraeder]

As discussed in #webextensions on irc.mozilla.org, jtk wants to talk to keeler about this issue.

15:40:31   twisniewski | are you deploying firefox in an enterprise setting?
15:40:45         pRiVi | twisniewski: What does that mean?
15:40:55         pRiVi | We are securing websites by client certificates
15:41:09   twisniewski | who are your users? do you work for a business, and are managing a set of computers for them with firefox?
15:41:18         pRiVi | this is what we get into trouble by firefox - just firefox - by removing the keygen
15:41:26         pRiVi | twisniewski: Home users
15:41:30         pRiVi | users of our customers
15:41:38         pRiVi | endusers
15:41:42         pRiVi | not able to do about:config
15:41:53         pRiVi | no domain, no domain controller, nothing
15:42:12         pRiVi | Chrome, IE, edge, .. works, on windows and on macos
15:42:25         pRiVi | but if you remove keygen, firefox will stop working for us
15:43:00          ntim | pRiVi: how does the extension fit into the story ?
15:43:05   twisniewski | ok, i understand. it sounds like this use-case has not been explored yet. but i don't believe we are planning to remove keygen before
                       | we explore it.
15:43:24   twisniewski | (even if there is a bug on file with a patch)
15:43:30         pRiVi | ntim: If I give the user a extension url, he can add this and then maybe make security.enterprise_roots.enabled
15:44:47           jkt | pRiVi: I don't really see why you need to give your users certs anyway
15:45:05         pRiVi | jkt: We secure webservers. https://www.cryptomagic.eu/cryptoweb/
15:45:10      freonbot | [ CryptoWeb ] - www.cryptomagic.eu
15:45:15         pRiVi | we have about 600 comapnies and about 12.000 users
15:45:30         pRiVi | the webservers are only available to users having a certificate
15:45:53         pRiVi | we must move ALL away from firefox to other browsers if keygen will go away
15:47:09       @zombie | ntim: run the test without your implementation, it should obviously fail, but test if it leaks
15:48:01         pRiVi | jkt: You can use your buggy, old, unpatched PHP server, and are still as secure as your users are not hackers.
15:48:31         pRiVi | jkt: and you can automatically login based on client installation not password or token
15:49:10         pRiVi | jkt: And, if you have a DDOS, you just can go easy to many, many servers.
15:49:14       @zombie | pRiVi: this doesn't sound like extensions issue, please post a comment in bug 1315460 or file another bug blocking it where you
                       | (calmly) describe your use case, and people will take it from there
15:49:15      freonbot | Bug http://bugzil.la/1315460 [e-mail], NEW, , P3, Remove support for HTML Keygen
15:49:44         pRiVi | zombie: will do, thanks.
15:49:48           jkt | pRiVi: yeah ^. It sounds like maybe we could hammer this out as an extension API perhaps.
15:50:06         pRiVi | jkt: so I should also file this?
15:50:26           jkt | there has been some talk about using the windows cert store but I think there are reasons not to do this

Comment 27

[Markus Schraeder]

Webauthn is currently no alternative cause of this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1481890

Comment 28

[Darkspirit]

Overview of possible solutions to finally remove the keygen tag:

1. Internet Standard
Mozilla, Cloudflare and Akamai are actively working on fixing an outstanding issue to make client certificates work with HTTP/2: https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-secondary-certs/

  1.1. File Handling: With bug 77355 and bug 773111 one might be able to create client certificates with WebCrypto,
       to import p12 files to prevent being dependant on OS certificate stores (bug 1482075) and to prevent losing
       some users to other browsers.

  1.2. WebExtension: bug 1088063 (as we already have bug 1357391).

2. Web Standard
bug 1481890

Comment 29

[Darkspirit]

Overview of possible solutions to finally remove the keygen tag:

1. Internet Standard
Mozilla, Cloudflare and Akamai are actively working on fixing an outstanding issue to make client certificates work with HTTP/2: https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-secondary-certs/

  1.1. File Handling: With bug 77355 and bug 773111 one might be able to create client certificates with WebCrypto,
       to import p12 files to prevent being dependant on OS certificate stores (bug 1120350) and to prevent losing
       some users to other browsers.

  1.2. Webcrypto API: bug 1088063

  1.3. WebExtension API: like we already have bug 1357391

2. Web Standard
bug 1481890

Comment 30

[Markus Schraeder]

@darkspirit: Donnot forget that bug #1529973 blocks this bug, the removing of the keygen-tag.

Comment 31

[Markus Schraeder]

Which was created as a duplicate as concretion of things to do in honor of bug #1481890 , which is the cause of blocking this bug, the removing of the keygen-tag.

Comment 32

[Markus Schraeder]

And why is bug #1315460 no longer blocking this bug, the removing of the keygen-tag?

Comment 33

[Markus Schraeder]

... of course I mean bug 1088063

Comment 34

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1315460 - Removal of keygen element

Comment 35

[Jonathan Kingston [:jkt] he/him]

The linker issues I had last time appear to magically have resolved themselves in the latest try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ff2d0358d70332a9aff8aed9af68f661748c9cb5

I will split out the changes into the htmlparser again assuming that tests are all passing.

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/381a74484140
Removal of keygen element r=keeler,baku,jld,hsivonen

Comment 37

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/381a74484140

Comment 38

[Kohei]

Posted site compatibility note: https://www.fxsitecompat.dev/en-CA/docs/2019/keygen-support-has-been-dropped/

Comment 39

[Markus Schraeder]

Webcrypto is NOT a replacement for using client interface certificates.

How is the new way to automatically import client certicates now? Why has this been removed if there is no one?

Comment 41

[Jonathan Kingston [:jkt] he/him]

Client certificates are still importable from the preferences panel which is the primary use case covered in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1088063 and further solutions are being discussed there.
As far as I am aware no other browser has automatic enrollment of client certificates and this is a privacy vector we don't want without a user having clear intent.

Bugs aren't really the correct place for discussion, I would like to direct you to https://groups.google.com/forum/#!msg/mozilla.dev.platform/SAh1b1R5lrY/UUHU2UNHAgAJ to continue this.

Comment 43

[Henri Sivonen (:hsivonen)]

https://hg.mozilla.org/projects/htmlparser/rev/fb6aaf9acc4d11c5c388a426f0c18183dc50fa49

Comment 44

[Eric Shepherd [:sheppy]]

Documentation updates:

• Submitted BCD PR 4605 labeling <keygen> as removed in Firefox 69
• Listed on Firefox 69 for developers

Comment 45

[Kai Engert [:KaiE:]]

Clarification question, do you intend to keep the ability to generate a key pair from within Firefox? I believe currently there isn't a way to trigger that, now that keygen has been removed. If you keep it, it would be useful for things like bug 1581796.

Comment 46

[Jonathan Kingston [:jkt] he/him]

:keeler is in a better position to answer our key generation APIs, redirecting to her.

Comment 47

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Client certificates have a number of drawbacks (privacy, ux, etc.), and so while Firefox will support them, we don't want to encourage their use going forward. Consequently, I don't see a reason for Firefox to support key pair generation (outside of webcrypto).