(Pre-)Intent to Deprecate: <keygen> element and application/x-x509-*-cert MIME handling

[Ryan Sleevi]

Primary eng (and PM) emails

rsl...@chromium.org

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.

[1] https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element

[2] 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]

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)

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])

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.

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.

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

[4] https://lists.w3.org/Archives/Public/public-html/2009Sep/0153.html

[5] https://blog.whatwg.org/this-week-in-html5-episode-35

[6] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen

[7] https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element

[8] 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.

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.

[9] https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement

[10] 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.

On some level, this removal will remove support for arbitrarily adding keys to the users' device-wide store, which is an intentional, by-design behaviour.

While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, and represents an authentication scheme that does not work well for the web. 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.

[11] https://developer.chrome.com/extensions/enterprise_platformKeys

[12] https://fidoalliance.org/

[12] 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

Usage information from UseCounter

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

Entry on the feature dashboard

https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement

Requesting approval to remove too?

No

[min...@sharp.fm]

On Tuesday, 28 July 2015 21:46:47 UTC+2, Ryan Sleevi wrote:

> Primary eng (and PM) emails
>
> rsl...@chromium.org
>
> 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].

Please dont.

If - and only if - a compelling replacement(s) for keygen are introduced and become widely and practically available, *then* consider dropping keygen. Until that time please leave it alone.

For an example of the embarrassment and chaos caused when Mozilla removed the crypto.signText API without checking with anybody, and without offering any replacement, see this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1083118

If keygen has shortcomings, fix them.

Regards,
Graham
--

[Ryan Sleevi]

On Tue, Aug 4, 2015 at 4:50 PM, <min...@sharp.fm> wrote:

For an example of the embarrassment and chaos caused when Mozilla removed the crypto.signText API without checking with anybody, and without offering any replacement, see this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1083118

I wouldn't call that embarrassment and chaos - that was Mozilla being good stewards of the platform and removing Browser-specific public APIs that have never been implemented by any other browser, nor would they be. While Mozilla ultimately decided to fund development of an extension to replace it, it did so primarily because it was clear that the software vendors were selling products with a clear intent to "only support Firefox", and were unwilling or unable to engineer solutions that were browser agnostic.

This sort of gets to the core point - whether or not it's a healthy function of a browser to encourage and enable developers to write sites that are browser-specific. The answer is, for most browsers, "Definitely not". That is, openness and interoperability is key.

So then the next question is whether <keygen>, window.crypto.signText, generateCRMFRequest, application/x-x509-*-cert, or any of these other "PKI management" functions have a role in the open web platform. And the answer there is, again, no; they're artifices of an early time when security was an afterthought and a rational, interoperable web platform that can scale to billions of devices - from your phone to your PC to your TV - was not a priority.

I know Mozilla does not view this as a success story - that is, that governments and banks rely on these non-standard features. Our own experiences with the vendors selling these governments/banks software is that they are some of the worst actors for standards compliance, and consistently fail to properly implement what they're supposed to for smart cards, so it comes as no surprise that they would use a variety of non-standard features (and worse, unnecessarily so, since they ended up developing plugins to support other browsers and they could have just done the same in Firefox).

However, none of this is relevant to <keygen>, for which the metrics - both crawler and real world usage - show there's virtually no usage, and there are alternatives for what Chrome has implemented (I clarify this to ensure that no improper parallels to Firefox are drawn, but even still, alternatives exist for Firefox as well)

[matt.we...@gmail.com]

Please do not deprecate this support.

1. There is extensive use of keygen provisioning and certificate usage for authentication within highly secure, closed networks (e.g. DoD, DIB) that Google does not have visibility on.
2. If you run a website and want to support cryptographically strong authentication for your clients without requiring them to change browsers or install different client software, your only option now is issuing client certificates. There is no similar replacement that is supported in major browsers by default. Even IE, while not directly supporting keygen, supports Javascript API's that can generate the same result, allowing scripts like IEkeygen.js to send the same data to the server.
3. There is also no alternative nearly as secure and frictionless for the general certificate issuance. For example, some CA's, if keygen could not be used, simply generated a private key and emailed it to the user for S/MIME certificates, HTTPS certificates, and code signing certificates. Alternatives generally involve pasting long command-line scripts into a terminal and/or complex manual certificate request specification/generation, both of which are extensively time-consuming, can pose graver security risks, and are more error prone.
4. If you run a website and want to prevent your clients from falling victim to a MITM attack without requiring a change in browser or the installation of different client software, your only option now is issuing client certificates. There are hundreds, if not thousands of root and intermediate CA's trusted by browsers, a compromise of any of them, which has happened many times before, results in loss of secure user data. By checking for client certificates, you can authenticate your clients and secure your communication channel even in the presence of CA compromise.

If you remove support for keygen, not only will you break many authentication systems, but even if such systems are re-written to support FIDO, you will end up with a worse scenario for end-user security:

Scenario 1 (keygen/certificates): User goes to website to set up account, clicks a button, certificate is automatically issued and stored in the browser. User can securely authenticate and browse.
Scenario 2 (FIDO): User goes to website to authenticate. Website informs user that to securely authenticate, user must install browser extension. User downloads and executes privileged code (browser extension) specified by arbitrary website.

FIDO relaxes the MITM protection that is strongest in certificates (it is not a required part of the protocol) and has some other technical characteristics that are concerning, and has governance issues that make it cost-prohibitive for a small business like ourselves to have a voice in the alliance, in contrast to more open standards processes. It is also a newer technology that does not have the decades of support client certificates do, which is why we prefer client certificates. The FIDO protocols nevertheless are a great improvement over most authentication systems in use today. But as it stands now, FIDO is far too young of a technology with too many flaws; not even deployed in most browsers by default, that it is not nearly ready to replace client certificates. Trying to do so introduces severe negative security externalities from flaws like training users to download and execute code to access a website that more than outweigh the advantages.

The author makes several assertions denigrating to client certificates for authentication that are given apparently without any justification: "While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, and represents an authentication scheme that does not work well for the web." The provisioning of a client certificate generally happens in a single click, which is the easiest authentication setup for any authentication system currently on the web. It is certainly easier than attempting to create and remember a unique and strong password, and at this point, significantly easier than FIDO as well. Client certificate-based authentication is used by millions of people for everything from web-based email: https://technet.microsoft.com/en-us/library/Cc995195.aspx to site authentication and more.

Client certificates have been an integral part of the TLS protocol for decades; since the first RFC's. They remain the best option for those who are concerned about very strong security and usability, and are indeed working well for millions of users. Deprecating keygen etc. would introduce incompatibilities and security and usability issues for many use cases. As the primary means of interacting with websites and authenticating organizations in general, browsers are the logical and safest means of handling this type of authentication with the least amount of friction for users. The loss of these abilities would be a blow to a more secure web.

[rek...@gmail.com]

One interesting capability that I think this feature did enable, that I don't think exists elsewhere: as user wanting to link-local advertise some services on my local laptop or cell phone, it is
A) imperative that I be able to use secure-origin features like getUserMedia, B) not an OK for every such user to have to go purchase certificates.

And that's where this very interesting capability that is Pre-Intent to Deprecate seems to be the perfect match. I'm a beginner here, but my understanding is that keygen would permit the above use case:
1) ZeroConf advertise on HTTP
2) Use keygen to host my cert
3) Then bounce clients to HTTPS
4) getUserMedia()

On the wild world wide web, I can see how letting people install random certs could be a bit of a scary mis-feature, one rife for abuse. But on the other hand, the link-local case is extremely compelling to me, and I'd like to be able to imagine that getUserMedia() & other secure-origin features have a future for the link-local web. Please, kindly, is there anything else that might be done to let getUserMedia() continue to be useable in the link-local world?

I've filed a ticket on the inability to do getUserMedia() in a link-local environment, and would love to hear ideas for how this capability might be preserved. I'll mention this reply shortly,
http://code.google.com/p/chromium/issues/detail?id=531675&thanks=531675&ts=1442264648

regards,
rektide

[rek...@gmail.com]

Keeping everything linked here- two weeks ago the PR to remove this feature from the WHATWG spec was first added and merged,
https://github.com/whatwg/html/pull/26

[Ryan Sleevi]

On Mon, Sep 14, 2015 at 2:58 PM, <rek...@gmail.com> wrote:

Please, kindly, is there anything else that might be done to let getUserMedia() continue to be useable in the link-local world?

No. What you described is not a viable/secure flow.

[rektide]

well that's a drastic dramatic response. peer to peer web: deprecated by the web/chorme. thanks google, thanks ryan, nice job crew, keep up the bang up work.

[Peter Bowen]

Maybe the description you gave was misunderstood. Let me try rephrasing:

1) Have a network of machines using link-local addressing and
zeroconf/mdns for name resolution and each running a HTTP server. Ex:
orange.local => 169.254.100.53
blue.local => 169.254.43.87
red.local => 169.254.207.92

2) Reply with a webpage containing the keygen element. Have the
client generate a new keypair, send to the server, and have the server
return a certificate.

3) The server then sends a redirect with the destination being the
same URL with the https scheme. The server requests a client
certificate which is used to authenticate the client.

I'm not clear the value here or how you expect this to work without
having a certificate for the server. How does the client authenticate
the server? How does keygen provide value?

Thanks,
Peter

> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev...@chromium.org.

[rek...@gmail.com]

On Tuesday, September 15, 2015 at 11:02:48 AM UTC-4, Peter Bowen wrote:
> Maybe the description you gave was misunderstood. Let me try rephrasing:
>
> 1) Have a network of machines using link-local addressing and
> zeroconf/mdns for name resolution and each running a HTTP server. Ex:
> orange.local => 169.254.100.53
> blue.local => 169.254.43.87
> red.local => 169.254.207.92
>
> 2) Reply with a webpage containing the keygen element. Have the
> client generate a new keypair, send to the server, and have the server
> return a certificate.
>
> 3) The server then sends a redirect with the destination being the
> same URL with the https scheme. The server requests a client
> certificate which is used to authenticate the client.
>
> I'm not clear the value here or how you expect this to work without
> having a certificate for the server. How does the client authenticate
> the server? How does keygen provide value?
>
> Thanks,
> Peter

Peter, thank you greatly for taking the time,

I have misunderstood the functionality of this element.

Thank you kindly for elaborating out the scenario and showing where pieces don't match up. Apologies to the list for applying my layman's understanding- I was replying in response to Chrome m47's secure-origin only getUserMedia() change, and engaged in overly much speculation that there could be a useable tool in keygen to get a link-local connection. I was definitely thinking the server also could generate it's own new key for the exchange. It's clearer to me rereading your reply & the spec this is not the case.

Glad we can make it through this.

[rahlente...@gmail.com]

> Usage information from UseCounter
> 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.
>

Features like these are often used in web applications (not websites) an on private enterprise networks. These applications are closed ecosystems which Google and other web crawlers can't access. HTTP, HTML and web browsers have far more uses than just "web pages".

[Graham Leggett]

While significant effort is being made to remove keygen for reasons that have never been properly explained, import of PKCS12 files containing key material of unknown origin is still supported across all the browsers:

https://support.globalsign.com/customer/en/portal/articles/2374828-in-browser-installation-of-client-certificates

PKCS12 has marginal/no security value at all, given that the key is by definition not private, and yet this security flaw persists across browsers.

While the Web Crypto API has been proposed as a replacement, this API explicitly disclaims any ability to do what either keygen or PKCS12 import do:

https://www.w3.org/TR/WebCryptoAPI/#scope-out-of-scope

Regards,
Graham
—

[Chris Palmer]

On Thu, Apr 20, 2017 at 9:10 AM, Graham Leggett <min...@sharp.fm> wrote:

While significant effort is being made to remove keygen for reasons that have never been properly explained,

Ryan Sleevi gave 6 very good reasons in his original message in this thread. Any 1 of those reasons would arguably be sufficient; all 6 together seal the deal.

import of PKCS12 files containing key material of unknown origin is still supported across all the browsers:

https://support.globalsign.com/customer/en/portal/articles/2374828-in-browser-installation-of-client-certificates

PKCS12 has marginal/no security value at all, given that the key is by definition not private, and yet this security flaw persists across browsers.

It's true that people should not install certificates and keys of unknown origin, but it's not true that all PKCS12 files are necessarily of unknown origin. It's just a file format.

Getting a certificate from your network administrator (or from yourself, such as when importing your Fiddler or Burp Proxy certificate) is a very different thing than getting one from web contents. If you're concerned about the questionable provenance of PKCS12 files (which, again, it's not always clear you should be), you should definitely be concerned about keygen elements in random web pages. (Reason 5 in Ryan's post.)

While the Web Crypto API has been proposed as a replacement, this API explicitly disclaims any ability to do what either keygen or PKCS12 import do:

I think that's OK (but I grant my perspective is limited). Key provision is really best done out of band (e.g. certificate files distributed by Group Policy Objects) rather than in/from web contents.

[Dirk-Willem van Gulik]

On 20 Apr 2017, at 18:18, 'Ryan Sleevi' via blink-dev <blin...@chromium.org> wrote:

On Thu, Apr 20, 2017 at 12:10 PM, Graham Leggett <min...@sharp.fm> wrote:

While significant effort is being made to remove keygen for reasons that have never been properly explained,

This is not true as a factual basis, but may merely represent an opinion. This thread provides

..... snip ...

While the Web Crypto API has been proposed as a replacement, this API explicitly disclaims any ability to do what either keygen or PKCS12 import do:

Yup. This is because what either <keygen> or (automatic) PKCS#12 do is neither secure nor respective of the Web's security foundations, nor, when used for OS configuration or influencing the behaviour of other applications or origins, appropriate. 

I think that is 'neither secure nor respective' is not true as a factual basis, but may merely represent an opinion. 

I cannot image it to be beyond the whit of mankind (or google engineering/browser engineers) to do keygen in a safe and secure fashion - or to manage its keys sufficiently well and, if the browser vendor feels that this is needed, isolated or partially isolated, from the OS if that is seen as a good thing*.

And while I totally agree that it is not an easy thing from a UI perspective; given how incredibly rarely one needs to use keygen - there is a lot of room to ensure that the right (and even somehwat laborious) interaction and prompting happens - and a lot of room to curtail naughty stuff in the background.

But none of this complexity seems to warrant killing of a very key (pun intended) element that secures the distributed open web; that makes it possible for entities to forge strong peer to peer trust relations; without a central broker, `login with xxx' button  or account 'master' or other dominant party being `in' on the trust setup.

Thanks,

Dw.

*: obviously other browser vendors may see it as very useful to cross the barrier to the OS (as it is very useful in a lot of distributed enterprise trust settings)  - and I am happy to let the market decide this.