Fwd: [blink-dev] Re: Intent to Remove: Keygen

FYI: There was a request from the chromium team to describe how the keygen
element is currently being used.

---------- Forwarded message ----------
From: Philip Jägenstedt <foolip@chromium.org>
Date: 26 November 2016 at 10:59
Subject: Re: [blink-dev] Re: Intent to Remove: Keygen
To: melvincarvalho@gmail.com, blink-dev <blink-dev@chromium.org>
Cc: svaldez@chromium.org, awhalley@chromium.org, rsleevi@chromium.org


On Sat, Nov 26, 2016 at 9:31 AM <melvincarvalho@gmail.com> wrote:

>
>
> On Tuesday, November 22, 2016 at 9:46:29 PM UTC+1, Ryan Sleevi wrote:
>
> *Primary eng (and PM) emails*
>
> rsl...@chromium.org, sva...@chromium.org, PM: awha...@chromium.org
>
>
> *Link to “Intent to Deprecate” thread*
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/
> pX5NbX0Xack/kmHsyMGJZAMJ (conclusion: https://groups.
> google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/vHDX0041BAAJ )
>
> *Summary*
> Remove support for all key types in <keygen>. As per the HTML spec, the
> element may continue to be recognized, but attempts to submit a form with
> this element will result in it providing a zero-length string, as defined
> by all versions of HTML that include <keygen> ( https://html.spec.whatwg.
> org/multipage/forms.html#the-keygen-element )
>
> *Motivation*
> As documented in the "Intent to Deprecate," thread, <keygen> poses
> systemic risk by modifying the permanent system, outside of the browsers'
> security model and the origin security model. It was introduced for
> purposes of device-wide configuration, not limited to TLS client certs (as
> reaffirmed on the Intent to Deprecate thread by those using it to provision
> S/MIME and other non-browser certs), and poses risks to user security. The
> lack of cross-browser support and the insufficient level of configurability
> that has lead to vendor-specific alternatives further indicate that
> <keygen> is not a desirable part of the Web Platform.
>
> *Compatibility Risk*
> Since Chrome 49, <keygen>'s default behaviour has been to return the empty
> string, unless a permission was granted to this page. This was originally
> scheduled for removal during Chrome 54, but to avoid any issues around
> holiday production freezes (and because of CA security incidents
> distracting from timely deprecation), this has been pushed back,
> tentatively targeting Chrome 57. This time was to allow sufficient
> migration time for enterprises relying on this feature for enterprise
> device provisioning, migrating to the OS-provided APIs. For non-enterprise
> cases, libraries such as PKIjs ( https://pkijs.org/ ) exist to address
> the use case of creating CSRs or downloading PKCS#12 files for import.
>
> *Usage information from UseCounter*
> From https://www.chromestatus.com/metrics/feature/
> popularity#HTMLKeygenElement , usage is at 0.0028%, well below the 0.03%
> upper bound for deprecation.
>
> UMA metrics indicate that 0.01% of users over 28 days have stored a
> permanent exception for a single domain, which is consistent with it
> primarily being an enterprise feature of limited scope
> (Metric: ContentSettings.Exceptions.keygen). Those who have stored for
> more than 1 domain, in aggregate, are approximately 0.001% of users, with
> the vast majority of that being stored at 2 domains.
>
> UMA metrics indicate that 0.10% of users over 28 days that have configured
> an explicit default setting have set a default policy of allowing <keygen>
> on all domains, despite the security risks identified (Metric:
> ContentSettings.DefaultKeygenSetting ). Of those, less than 0.001% are
> set via enterprise policy, indicating there is no longer a strong
> enterprise need to maintain support (Metric: Enterprise.Policies).
>
> These metrics are consistent with the Intent to Deprecate, that the
> feature is rarely used in practice, and when it is used, it is for a
> limited set of domains.
>
>
> -1
>
> This element is in use.
>
> Please do not deprecate, until a suitable replacement is available.
>

Can you elaborate on how you are using keygen?