Intent to Remove: Keygen

[Ryan Sleevi]

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.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=667876

https://blog.chromium.org/2016/02/chrome-49-beta-css-custom-properties.html

Entry on the feature dashboard

https://www.chromestatus.com/features/5716060992962560

[Domenic Denicola]

Great to see progress on this overall.

From: sle...@google.com [mailto:sle...@google.com] On Behalf Of Ryan Sleevi

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

Will the UI be retained, and just always submit nothing?

Is there interest in eventually sunsetting the <keygen> element entirely, as has been done with e.g. <applet> in Chrome? This would mean that it no longer shows up in the form data set at all; the HTMLKeygenElement would be removed; and various form-related things would change (e.g. it would not appear in form.elements). There's also an optional step of removing parser support for it, although for <applet> the conclusion was to not change the parser.

[Ryan Sleevi]

On Tue, Nov 22, 2016 at 1:34 PM, Domenic Denicola <d...@domenic.me> wrote:

Will the UI be retained, and just always submit nothing?

With the RSA keytype removed, the UI itself becomes a no-op/non-rendering. That is, the UI of the element is tied to supported keytypes, as per https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element (specifically, "The user agent may expose a user interface for each keygen element to allow the user to configure settings of the element's key pair generator, e.g. the key length." - the key pair generator is tied to the algorithm in the keytype)

 

Is there interest in eventually sunsetting the <keygen> element entirely, as has been done with e.g. <applet> in Chrome? This would mean that it no longer shows up in the form data set at all; the HTMLKeygenElement would be removed; and various form-related things would change (e.g. it would not appear in form.elements). There's also an optional step of removing parser support for it, although for <applet> the conclusion was to not change the parser.

On that, I suppose that'd be a question for the HTML Standard and seeing if there is cross-browser agreement on that. I certainly think that would make logical sense.

[Domenic Denicola]

From: sle...@google.com [mailto:sle...@google.com] On Behalf Of Ryan Sleevi

> On that, I suppose that'd be a question for the HTML Standard and seeing if there is cross-browser agreement on that. I certainly think that would make logical sense.

Sounds good. I've opened https://github.com/whatwg/html/issues/2079 to discuss. It's notable that Edge does not support keygen at all so we're already 1/4 of the way there.

[Mike West]

Non-OWNER's LGTM. This is a logical conclusion of the deprecation we started, and the metrics (and Edge's lack of support) show low enough usage that there's little risk of user-facing breakage.

I agree with Domenic that removing the element's special behavior is a reasonable goal. Presumably that's Edge's behavior today? It might be a better idea to align with that behavior in one step, as opposed to introducing a third behavior (empty string) inbetween.

-mike

[Philip Jägenstedt]

A small test of existing behavior: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/4687

• Chrome and Safari have an HTMLKeygenElement interface and some <select>-like UI.
  
• Firefox actually seems to replace it with a special <select> at parse-time, and document.createElement('keygen') returns an HTMLSpanElement.
  
• Edge seems to recognize it in the parser as it's an HTMLElement and not an HTMLUnknownElement, but seems to otherwise not do anything with it.
  

I would favor matching Edge's behavior, as having a neutered HTMLKeygenElement that cannot do anything would be a new situation, so attempting to match another implementations seems better. It's also what I assumed would happen from the deprecation message, "The <keygen> element is deprecated and will be removed ..."

Ryan, does that sounds OK, or have I overlooked some reason for preferring to remove all key types while leaving the HTMLKeygenElement API intact?

[Boris Zbarsky]

On 11/23/16 5:06 AM, Mike West wrote:
> Non-OWNER's LGTM. This is a logical conclusion of the deprecation we
> started, and the metrics (and Edge's lack of support) show low enough
> usage that there's little risk of user-facing breakage.

For what it's worth, the metrics may understate user-facing breakage in
this case.

As a specific example, here's a site I know that uses keygen: the one
that MIT uses to create user certificates that are then used by students
to access all the secure web stuff the university has. This is a site
that each student would typically access once a year or so, when the
user cert expires (usually in August). Note that inability to generate
the user cert means inability to access anything that requires a "login"
on the MIT infrastructure, or did last I checked.

What would that usage pattern look like in the metrics data?

Now it's true that the set of people who need to access MIT's secure
stuff is small in the grand scheme of things: ~10-20k people. So in
that sense even breakage like "can't use anything at all" is small in
user-site-visit percentage terms.

-Boris

P.S. I just looked into how they handle the certificate thing in Edge.
They do it by having a Windows app that you download and run that
generates the certificates and puts them into the Windows certificate
store. If you're a Chrome user on Linux, you're SOL without keygen
support in their current setup.

[Ryan Sleevi]

On Wed, Nov 23, 2016 at 2:38 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Ryan, does that sounds OK, or have I overlooked some reason for preferring to remove all key types while leaving the HTMLKeygenElement API intact?

Meh, mostly because I knew how to remove keytypes safely, and the proposal fit with the HTML spec. Replacing it with a neutered element is something I'm not familiar with, and thus will be a much larger learning curve (and a question for M57), but if it matches Edge, sure.

[Ryan Sleevi]

On Wed, Nov 23, 2016 at 7:37 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

For what it's worth, the metrics may understate user-facing breakage in this case.

I'm not sure that we can conclude it would understate breakage. The metrics would show it's a rarely used element. Should it be kept along if it's used by 20,000 users once a year? Is that an acceptable implementation cost to pass on to a billion+ users?

The metrics I mentioned looked at users who had stored at least one exception granting the <keygen> permission to an origin. In effect, if any user had visited that MIT site, they would have stored the exception for that site. That number would still be captured in the metrics, even though it looked at a 28DA window, if the user used Chrome at all in those 28 days. That is, independent if they actually used <keygen> in those 28 days, if they had previously used <keygen>, and not revoked the permission (which we can assume users are unlikely to do, in general), then it would have been reported.

So we can then determine that 0.01% of users have used <keygen> at all since the metric was introduced (roughly a year ago) and not revoked the permission (which we assume users are unlikely to do). That still sits below the bar of 0.03%. The 0.0028% represents the number of times, within that window, that the element has been seen - which is still small.

 

As a specific example, here's a site I know that uses keygen: the one that MIT uses to create user certificates that are then used by students to access all the secure web stuff the university has.  This is a site that each student would typically access once a year or so, when the user cert expires (usually in August).  Note that inability to generate the user cert means inability to access anything that requires a "login" on the MIT infrastructure, or did last I checked.

The MIT case was previously discussed in the I2D thread.

 

What would that usage pattern look like in the metrics data?

If they used MITs site, it would have been captured in >=1 exception, unless they revoked it, which is not part of the MIT flow.

 

P.S.  I just looked into how they handle the certificate thing in Edge. They do it by having a Windows app that you download and run that generates the certificates and puts them into the Windows certificate store.  If you're a Chrome user on Linux, you're SOL without keygen support in their current setup.

As mentioned in the I2D thread, it's trivial to replace the MIT case with pkijs.org generating PKCS#12, and have the same security assurances that MIT is currently relying on, with an easier UI flow (fewer clicks to import). The automatic installation of certificates was already removed a year ago to non-issue, and the JS flow would eliminate the need for the permissioned grant. Despite its ease in polyfilling in JS, the browser implementation itself can't be transparently updated to match the JS flow, because we know that breaks how <keygen> works for some sites, and fixing that would require introducing new per-origin storage flows or injecting stuff in script-visible ways (e.g. stashing it in localStorage).

[Chris Harrelson]

LGTM1

I see no new data to overrule the decision we reached in the Intent to Deprecate thread, after a lengthy and detailed discussion. Thank you for the detailed report in this Intent as well.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

To be clear, by "a neutered HTMLKeygenElement that cannot do anything" I meant the outcome of removing only the keytypes.

I think that in order to make it look like Edge, it should suffice to put "keygen interfaceName=HTMLElement" in HTMLTagNames.in and remove everything that says "HTMLKeygenElement" until it compiles, but that's probably best discussed in review.

LGTM2 to remove in an as Edge-like manner as possible, unless something comes up that makes a more limited removal more attractive.

[melvinc...@gmail.com]

-1

This element is in use.

Please do not deprecate, until a suitable replacement is available.
 

[Philip Jägenstedt]

Can you elaborate on how you are using keygen?

[henry...@gmail.com]

yes, we are using it for building a distributed secure social web described in the SoLiD project

    https://github.com/solid/solid

The way we use keygen is described here:

    https://www.w3.org/2005/Incubator/webid/spec/tls/#certificate-creation

The rest of that document shows how we then use it for authentication using TLS.

This ties into a number of other existing standards and tested proofs of concepts listed here (and also described on the SoLiD page)

   https://www.w3.org/2005/Incubator/webid/spec/

These don't all require TLS client certificate authentication btw.  I personally tried using WebCrypto API - 

which has a function to create keys - as a replacement and wrote up the conclusions I came to here:

   https://github.com/solid/solid-spec/issues/52

I was able to use the keys generated to have a JS application authenticate across origins, which is one use case we need.

The problem with the web crypto API that I can remember are

  1) that one cannot guarantee to the client that the private key is not sent to the server

  2) there is no chrome support for using the key (as there is with client certificates) which means

      • that every application may have a different way to present the user for a certificate creating confusion

      • that the user has to completely trust the application about the use of the keys

  3) There is no way to identify the browser itself across origins (which after all is an application) as opposed to origin

     bound applications (whilst giving control to the user)

The use of identification across origins is obvious when one considers distributed social networks.

Now there is also a W3C TAG review of this problem

   https://w3ctag.github.io/client-certificates/

Btw. it is agreed that client certificate renegotiation do not tie in very well with HTTP/2.0, but

it is useful enough for us to show how we can make use of it. As I understand there is work on 

creating tie-ins with TLS and HTTP/2.0 such as the following

   https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-02

So that's a brain dump. If you want to talk more about this you can contact me personally.

I am currently working on a PhD at Southampton on the subject.

Henry Story

http://co-operating.systems/

  

  

 

[dir...@gmail.com]

Not a good idea IMHO. Things that spring to mind are:

1. The suggested 'replacements' are not that - they do not allow for non-centralized/coordinated use (due to things like site policy). And it is this very feature of the web (that one does not have to ask a platform owner to implement something; or overly rely on a central broker) that embodies its value for an open democratic society.
2. Until we have a replacement - this is another stone against the OpenWeb and federated authentication specifically. Lets not kill that before we have an replacement. Not every collective of federated parties that needs to collaborate wants to be collectively forced to use FaceBook or Google as their neutral authentication platform (or whatever a Nation dictates domesticaly).
   
3. This technology is in wide use in enterprises, at NGOs and (semi) public organisations. 
4. I suspect that the UseCounter statistics are a bit misleading; even at the most security cautious NGOs where this is in use & there is regular forced rekeying - the average employee would only visit the keygen page a few times a year - against, say, millions of page visits of their internal webmail. (And besides; all users of keygen that I am  personally familiar with have all policies (or automated rollouts) that block (anonymous) reporting of statistics).
5. The MS comparison is not quite a fair one - existing solutions have long relied on the exact same solution with Enroll.DLL (and friends); a solution that has let open, federated, interoperable client side cert authentication work pretty much unchanged for over 20 years.
6. While I acknowledge that the risk and potential harm of keygen in the code base are real -- the mono-culture aspects and diversity-reducing economic forces unleashed by the alternatives suggested are IMHO a larger risk to the web as a whole; and not as easily fixed by code. So I rather focus on code & getting keygen better. That is a problem we know we can keep under control.

But finally - and almost most of all - the little anarchist in me just loves the fact that you can do unadulterated federated authentication without having to coordinate with 'the man' and without having to 'collude' with others. Just set whom you trust - - and presto. That is the Open Web !

Dw.

[PhistucK]

On Tue, Nov 22, 2016 at 10:45 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

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

​Or... It means the enterprises are mostly disabling usage statistics.​

☆PhistucK

[Ryan Sleevi]

We can speculate about the infinite possibilities of what we don't know.

Or we can act on what we do know.

More generally, this is the criteria we've set out on how to measure things, and we communicate to enterprises that this plays an important role in support and measuring usage. While it's reasonable to speculate that the possibility exists that nearly every enterprise consumer of keygen is equally one that has disabled metric reporting, it's somewhat easier and pragmatic to apply Occam's Razor.

[Melvin Carvalho]

While I do have a number of use cases for keygen, and several million pages that use it, but I think Travis Leithead (Microsoft) wrote up the issue far better than I could. 

https://w3ctag.github.io/client-certificates/

I agree with the W3C Technical Architecture Group, that there is currently no like for like replacement for this functionality, and so should only be deprecated when there is consensus that there is a suitable replacement.

There has been pushback on this from crypto developers, web developers, free and open source developers and enterprise developers. 

I think that deprecating this element and providing something better (something everyone would like to see) would be a win-win, but deprecating it prematurely would be a lose-lose.  Both from a technical and a business perspective.

[Alex Russell]

As a TAG member involved in drafting that document, I'd strongly caution you against misrepresenting what was a carefully worded statement on our part.

What we wrote is summarized at the end with:

...

Given these requirements, we recognize that an "improved keygen element" could be built using the new solution as a foundation (e.g., using web components).

We also call on implementations to improve the client certificate UI experience in order to make client-certificate use in authentication more accessible to general users.

None of this is incompatible with Chrome's push to remove the current <keygen> element implementation. We have provided guidance for folks who wish to start a new effort on an element that is fit for purpose (which for reasons we also documented, <keygen> is not).

If you'd like to make the case for starting such an effort, I recommend the WICG as a venue for incubating nascent ideas: https://discourse.wicg.io/

Regards

--

[Philip Jägenstedt]

Melvin, I didn't realize when asking, but I see that Ryan already engaged with you and Henry on the deprecation thread, and the use cases around WebID were known at that time.

My LGTM2 stands, I thought perhaps there was new information.

[Ryan Sleevi]

Can I get another LGTM from a Blink API Owner (3 are needed, right?)

[Henry Story]

On 29 Nov 2016, at 13:14, Philip Jägenstedt <foo...@chromium.org> wrote:

On Mon, Nov 28, 2016 at 1:00 PM Melvin Carvalho <melvinc...@gmail.com> wrote:

On 26 November 2016 at 10:59, Philip Jägenstedt <foo...@chromium.org> wrote:

On Sat, Nov 26, 2016 at 9:31 AM <melvinc...@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?

While I do have a number of use cases for keygen, and several million pages that use it, but I think Travis Leithead (Microsoft) wrote up the issue far better than I could.  

https://w3ctag.github.io/client-certificates/

I agree with the W3C Technical Architecture Group, that there is currently no like for like replacement for this functionality, and so should only be deprecated when there is consensus that there is a suitable replacement.

There has been pushback on this from crypto developers, web developers, free and open source developers and enterprise developers.  

I think that deprecating this element and providing something better (something everyone would like to see) would be a win-win, but deprecating it prematurely would be a lose-lose.  Both from a technical and a business perspective.

Melvin, I didn't realize when asking, but I see that Ryan already engaged with you and Henry on the deprecation thread, and the use cases around WebID were known at that time.

My LGTM2 stands, I thought perhaps there was new information.

Euh, yes, you elected Donald Trump in the mean time....

Good luck.

Henry

-- 
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/z_qEpmzzKh8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

[Dimitri Glazkov]

LGTM3.

[om...@trusphere.com]

Ryan, et al.,

In the I2D thread, the third use case listed was the following:

• Multi-factor authentication provisioning (e.g. StartSSL) - using TLS authentication for multi-factor authentication. An example is https://www.startssl.com.

I did not check the StartSSL website in mid-September 2015, but checking it today, it looks to me like StartSSL is performing certificate provisioning for TLS client authentication as the primary factor for authentication with the StartSSL website (the login cert can also be used for S/MIME).

Such a use case - provision certificate for TLS client authentication with a non-enterprise website - is the use case that I have been actively trying to enable for my own companies' websites and other companies' websites.  TLS client authentication can certainly be used as a more seamless second factor of authentication, but its potential as an outright replacement for passwords as the primary factor of authentication for consumer-facing Internet websites is what's most appealing.

I'm not talking about smart cards for government IDs or certificates that need to be multi-origin like the Web ID folks desire.  I am talking about TLS client certificates for each user for each of their existing devices for each of their websites (aka per-origin).  For a user's browser, not some other application on the user's device.  With the right guidance, all businesses could implement this today as long as basic building blocks like keygen remain available.  We do not need to wait for new browsers or new standards or literally billions of users to go buy new whatever-standard enabled devices.  We can do this today and upgrade the solution over time as all those new standards / devices come online and become the new ubiquitous web platform.

One of the most critical parts of enabling such a use case is the user experience for provisioning the user's device certificate for a particular website.  Relatively speaking, Chrome, especially before Chrome 49 when keygen was still enabled by default, had one of the relatively best user experiences amongst browsers.  Chrome 48 and earlier let a user know something happened in response to their actions - a progress bar while key gen is in progress and a nice little info bar when the certificate response was received - without prompting the user to take an unnecessary action or to perform an action that he/she likely would not understand.  Importantly, from a security perspective, keygen also allows for the private key to be generated on a user's device.

In both the I2D and this I2R thread, you have suggested that Web Crypto and JavaScript provide superior usability alternatives to keygen + x-x509-user-cert, but please try signing up with  https://www.startssl.com in 3 different configurations (say, on Mac OS X 10.11): (1) Chrome 48, (2) default Chrome 49+ (w/ keygen disabled), and (3) non-default Chrome 49+ with keygen enabled.

While the StartSSL folks are not using PKIjs, they are more or less doing what you have sketched out previously, but I do not understand how you have concluded that such a JS-based flow results in "an easier UI flow (fewer clicks to import)."  Here is the extra UI stuff that I see with a JavaScript solution:

(1) Prompt for a P12 password [at least on Mac OS X 10.11, you cannot import a P12 through the UI with an empty password; user confusion right off the bat: why do I need a password still?]
(2) Click to download the P12 [though this could potentially be automatically downloaded with (1)] [NOTE: For some reason StartSSL asks to download CA chain too, but this is not necessary for TLS auth with their website]
(3) Click to open the downloaded P12, bringing up default OS Cert UI
(4) Enter the P12 password from (1)
(5) Navigate back to Log In [this is not unique to JS-flow]
(6) Select certificate [this is not unique to JS-flow]
(7) Grant permission to Chrome's use of private key associated with (6) [this is unique to JS-flow; will user always allow?  if not, this has to be repeated]

So that's at least 4-5 extra UI interactions (1/2,3,4,7) in the JavaScript flow that are not required in the keygen+x-x509-user-cert flow.  In StartSSL's case, it seems like they're not generating and downloading the P12 on the client-side, but generating and downloading it from the server.  They could generate the P12 on the client-side to keep the private key local to the device, but if you want to split the cert request / cert response apart like you can do with keygen, it's not obvious to me how to achieve this in JavaScript, especially across restarts of the browser.  Also, the P12 will remain in the download area on disk, unlike being only in the OS's cert store.

With regards to some of the other security points that have been raised, I would like to comment on a couple of those: signing the public key on the cert request with MD5withRSA is obviously poor, but this can be mitigated by performing form submission over TLS with properly configured modern key exchange / ciphers.  The certificate in the response can be signed with any modern algorithm and can also be delivered over properly configured TLS.  With regards to other apps having access to the certs / key pairs, default access control seems to be limited to the installing app on some platforms (like Mac and Linux), and origin control can be mitigated by TLS servers specifying the acceptable list of client CAs.

I am not asking to hold off on removal of keygen + x-x509-user-cert because I think the status quo is the best that we can do, but status quo tech still has tons of potential at a critical time while new and better options are still getting implemented and deployed to the same scale.  Obviously, Google has thrown its weight behind FIDO and Web Authentication, and I hope one or both of those solutions do eventually succeed, but I just do not understand the urgency to remove status quo tech like keygen until the new tech is much farther along. The status quo is obviously filled with lots of conventions and best practices, but valid solutions have been built with the status quo that can solve very important and pressing problems still plaguing the modern web.

Please re-consider holding off removal, and ideally, also reverting the default keygen behavior to like Chrome 48.

[BTW, Web ID folks: given that TLS servers can broadcast the list of acceptable CAs for client certificates, which most user agents honor, including browsers like Chrome, I do not understand why a TLS server cannot be configured to accept whatever CAs are desired - to get as much "openness" / "socialness" as you want.  If needed, could you not stand up a Web ID CA repository where entries could be added / removed / queried with as little or as much oversight as needed?  That whole discussion about per-origin vs. all-origins distracted from the main collective desire: not losing keygen prematurely.]

-Omar

[Ryan Sleevi]

On Tue, Nov 29, 2016 at 7:05 PM, <om...@trusphere.com> wrote:

• Multi-factor authentication provisioning (e.g. StartSSL) - using TLS authentication for multi-factor authentication. An example is https://www.startssl.com.

I did not check the StartSSL website in mid-September 2015, but checking it today, it looks to me like StartSSL is performing certificate provisioning for TLS client authentication as the primary factor for authentication with the StartSSL website (the login cert can also be used for S/MIME).

Such a use case - provision certificate for TLS client authentication with a non-enterprise website - is the use case that I have been actively trying to enable for my own companies' websites and other companies' websites.  TLS client authentication can certainly be used as a more seamless second factor of authentication, but its potential as an outright replacement for passwords as the primary factor of authentication for consumer-facing Internet websites is what's most appealing.

In general, this should not be used for new deployments, certainly not for public deployments. THis was mentioned in the I2D thread, enumerating the numerous issues with TLS CCAs. But setting aside the very real problem they pose (and why FIDO/WebAuthN is a much more suitable, privacy preserving replacement), this use case is fully met with PKIJs.

 

I'm not talking about smart cards for government IDs or certificates that need to be multi-origin like the Web ID folks desire.  I am talking about TLS client certificates for each user for each of their existing devices for each of their websites (aka per-origin).  For a user's browser, not some other application on the user's device.  With the right guidance, all businesses could implement this today as long as basic building blocks like keygen remain available.  We do not need to wait for new browsers or new standards or literally billions of users to go buy new whatever-standard enabled devices.  We can do this today and upgrade the solution over time as all those new standards / devices come online and become the new ubiquitous web platform.

Actually, this would be rather terrible for the web, for reasons unrelated to <keygen>. But it's important to at least point out that, as the goal is undesirable, so too is the intermediate.

 

One of the most critical parts of enabling such a use case is the user experience for provisioning the user's device certificate for a particular website.  Relatively speaking, Chrome, especially before Chrome 49 when keygen was still enabled by default, had one of the relatively best user experiences amongst browsers.  Chrome 48 and earlier let a user know something happened in response to their actions - a progress bar while key gen is in progress and a nice little info bar when the certificate response was received - without prompting the user to take an unnecessary action or to perform an action that he/she likely would not understand.  Importantly, from a security perspective, keygen also allows for the private key to be generated on a user's device.

Having implemented this as my first Chromium contribution, I can authoritatively and definitively state it was the least secure, and most error prone of implementations, in ways that fundamentally would have required significantly more investment that is not commiserate with either it's real world usage or it's potential use cases.

 

(1) Prompt for a P12 password [at least on Mac OS X 10.11, you cannot import a P12 through the UI with an empty password; user confusion right off the bat: why do I need a password still?]

This is not a necessary condition of your workflow. While newer versions of macOS require a password, an empty password (the empty string) is valid, or equally, "password". There's no need to prompt the user for the password.

 

(2) Click to download the P12 [though this could potentially be automatically downloaded with (1)] [NOTE: For some reason StartSSL asks to download CA chain too, but this is not necessary for TLS auth with their website]

Right, you can trigger the download with a content-disposition and a blob URL. So this step is unnecessary.

 

(3) Click to open the downloaded P12, bringing up default OS Cert UI

This is a security mitigation.

 

(4) Enter the P12 password from (1)

This is unique to macOS

 

(5) Navigate back to Log In [this is not unique to JS-flow]
(6) Select certificate [this is not unique to JS-flow]

Correct

 

(7) Grant permission to Chrome's use of private key associated with (6) [this is unique to JS-flow; will user always allow?  if not, this has to be repeated]

This is a macOS idiom with keys created outside of the app on newer versions of macOS. Which is good and desirable, since Chrome shouldn't automatically have access or be using keys in the users' keychain.

 

So that's at least 4-5 extra UI interactions (1/2,3,4,7) in the JavaScript flow that are not required in the keygen+x-x509-user-cert flow. 

To be clear: Step 2 is unnecessary, Step 1/4 are artifacts of macOS. Steps 3/7 are unique, but they're also part of the minimum necessary steps for <keygen>. So they're not unique to "secure <keygen>".

 

They could generate the P12 on the client-side to keep the private key local to the device, but if you want to split the cert request / cert response apart like you can do with keygen, it's not obvious to me how to achieve this in JavaScript, especially across restarts of the browser.

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API (for which many libraries exist to make it look like a cleaner, async version of https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API )

 

  Also, the P12 will remain in the download area on disk, unlike being only in the OS's cert store.

Correct. But from Chromium's POV, that's no change in functionality or security: https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-

 

With regards to some of the other security points that have been raised, I would like to comment on a couple of those: signing the public key on the cert request with MD5withRSA is obviously poor, but this can be mitigated by performing form submission over TLS with properly configured modern key exchange / ciphers.  The certificate in the response can be signed with any modern algorithm and can also be delivered over properly configured TLS. 

That doesn't mitigate the issues or concerns raised.

 

With regards to other apps having access to the certs / key pairs, default access control seems to be limited to the installing app on some platforms (like Mac and Linux),

That's not correct for Linux (it's not app restricted), neither for Windows. It is true for Android and iOS, but <keygen> and client certs are not handled by us on iOS anyways, and on Android, you can't escape the prompts (that is, both <keygen> and PKIjs result in the same UX).

So really, your complaint is the additional UI introduced by macOS requiring a passworded-PKCS#12 file, the click (to load the file in the OS viewer), and having to reenter the password. I agree, these are differences, but they're not meaningful differences in the overall UX. Further, in terms of number of clicks, they're the same number of clicks a 'fixed' <keygen> would require, setting aside all the other issues semantically with the element.

 

and origin control can be mitigated by TLS servers specifying the acceptable list of client CAs.

The origin control being mitigated by the TLS server fails to understand the threat model - which is that the server is not trusted. That is, the goal is to ensure the browser can talk to an untrustworthy server and 'do the right thing'. It can't with TLS client certs (it relies on the server being nice), but can with other technologies (such as FIDO).

 

but I just do not understand the urgency to remove status quo tech like keygen until the new tech is much farther along.

These were covered in the I2D.

[henry...@gmail.com]

w

On Tuesday, 29 November 2016 23:34:22 UTC+1, Henry Story wrote:

On 29 Nov 2016, at 13:14, Philip Jägenstedt <foo...@chromium.org> wrote:

On Mon, Nov 28, 2016 at 1:00 PM Melvin Carvalho <melvinc...@gmail.com> wrote:

The EFF's statement with regard to that:

   https://www.eff.org/files/2016/12/20/eff-final-2-ad-sm.pdf

 

Henry

-- 
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/z_qEpmzzKh8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.