Agenda: <keygen> being destroyed when we need it

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Agenda: <keygen> being destroyed when we need it

Tim Berners-Lee
Folks

There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.

<keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.

Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.

Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.


It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.

Keygen is not therefore something which you can just code in Javascript. 

The original July 28  announcement from the Chrome team is here:

My response to that is here: 

I attached an attempt to recreate the indentation of text/response which got messed up in some versions.

Let's put this on the TAG agenda.

Tim



On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:

   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.


Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.


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


Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.


   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)


If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until


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


A solution would be then to extend the standrad in future versions and code compatibly to that.


   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.


Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time

If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?



   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.


There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.

If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly

   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.


Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.




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


The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.





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


I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.

   While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 


What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,




   and represents an authentication scheme that does not work well for the web. 


Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?



   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.


Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.

In the mean time, please fix bugs in client certs which are just a pain.

- Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
- Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.

- In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)

So don't abandon <keygen>, fix it.

And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  

In the meantime please support keygen and improve client cert handling. 

timbl









   [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


Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Anders Rundgren-2
Dear Tim & Co,

The really big destruction happened a while ago when Google and Microsoft decided to deprecate "plugins".

This forced millions of European and Asian users of digital signatures to switch from the Web to Apps.
No replacement has ever been considered by the TAG or other W3C forum.

Sincerely,
Anders Rundgren


On 2015-09-01 16:08, Tim Berners-Lee wrote:

> Folks
>
> There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.
>
> <keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.  For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.
>
> Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.
>
> Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.
>
>
> It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.
>
> Keygen is not therefore something which you can just code in Javascript.
>
> The original July 28  announcement from the Chrome team is here:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack/discussion <https://groups.google.com/a/chromium.org/forum/#%21topic/blink-dev/pX5NbX0Xack/discussion>
>
> My response to that is here:
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/5CQnw56-BQAJ
>
> I attached an attempt to recreate the indentation of text/response which got messed up in some versions.
>
> Let's put this on the TAG agenda.
>
> Tim
>
>
>
> On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:
>
>>    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.
>>
>>
> Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.
>
>>
>>    [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]
>>
>>
> Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.
>
>
>    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)
>
>
> If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until
>
>>
>>    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])
>>
>>
> A solution would be then to extend the standrad in future versions and code compatibly to that.
>
>
>>    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.
>>
>>
> Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time
>
> If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?
>
>
>
>>    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.
>>
>
> There is a typical browser vendor mindset: this feature allows a web site to do something to the user.
> Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.
>
> If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly
>
>>    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.
>>
>>
>> Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.
>>
>>
>>
>>
>>    [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.
>>
>
> The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.
>
>
>
>
>>
>>    On some level, this removal will remove support for arbitrarily adding keys to the users' device-wide store, which is an intentional, by-design behavior.
>>
>>
> I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.
>
>>    While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability,
>>
>>
> What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,
>
>
>
>>
>>    and represents an authentication scheme that does not work well for the web.
>>
>
> Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?
>
>
>
>>    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.
>>
>
> Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.
>
> In the mean time, please fix bugs in client certs which are just a pain.
>
> - Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
> - Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.
>
> - In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)
>
> So don't abandon <keygen>, fix it.
>
> And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.
>
> In the meantime please support keygen and improve client cert handling.
>
> timbl
>
>
>
>
>
>
>
>
>
>    [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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Melvin Carvalho
In reply to this post by Tim Berners-Lee


On 1 September 2015 at 16:08, Tim Berners-Lee <[hidden email]> wrote:
Folks

There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.

<keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.

Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.

IMHO we need an area of the browser under a user's control
 

Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.


It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.

Keygen is not therefore something which you can just code in Javascript. 

The original July 28  announcement from the Chrome team is here:

My response to that is here: 

I attached an attempt to recreate the indentation of text/response which got messed up in some versions.

Let's put this on the TAG agenda.

Tim



On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:

   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.


Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.


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


Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.


   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)


If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until


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


A solution would be then to extend the standrad in future versions and code compatibly to that.


   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.


Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time

If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?



   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.


There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.

If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly

   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.


Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.




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


The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.





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


I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.

   While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 


What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,




   and represents an authentication scheme that does not work well for the web. 


Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?



   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.


Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.

In the mean time, please fix bugs in client certs which are just a pain.

- Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
- Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.

- In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)

So don't abandon <keygen>, fix it.

And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  

In the meantime please support keygen and improve client cert handling. 

timbl









   [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



Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Henry Story-3
In reply to this post by Tim Berners-Lee
A few additional details below.

On 1 Sep 2015, at 16:08, Tim Berners-Lee <[hidden email]> wrote:

Folks

There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.

I opened an issue on the WHATWG's recently moved to (and therefore perhaps not yet widely known) github repository yesterday after the <keygen> deprecation commit had been pushed to master.


This issue was then closed within a few hours ( citing the fact that the commit had already been pushed)

I then sent a mail to the whatwg mailing list, where this issue had clearly not been discussed nor brought up:

This recent discussion was split over now at least 5 different lists. Similar arguments come up in these different lists, requiring repeatedly similar points to be made. In many cases on questioning an argument I vaguely pointed to debates that happend on other lists. All in all the key arguments are very hard to come by. One gets a strong feeling of decisions being made by secret evidence.  This is very similar to when reference to not yet deployed technology from other standards organisation ( eg. FIDO ) is made to support the argument to retract keygen. Finally the criteria of security vary widely. Hypothetical security issues of keygen are put forward by the same people who then feel no problem with the fact that current JS APIs produce keys that have to be stored in the browser local storage and are then made available to all other applications of the same origin.

My suggestion is that a full list of problems and advantages of keygen and indeed the wider security space needs to be drawn up. These have to be evaluated against various often conflicting criteria. ( Eg. is centralisation less problematic than privacy? ) Such a detailed map could then be used to improve either keygen, an equivalent JS api, or even at some point help comparison with other technologies such as FIDO.

It is only by going through these problems in detail and in the open that there is any chance of finding out what is broken and what needs improving in the web security space.

Listening to actual users of the technology would also be helpful.

( Btw. is there an HTML WG too I should post this to? )


<keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.

Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.

Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.


It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.

Keygen is not therefore something which you can just code in Javascript. 

The original July 28  announcement from the Chrome team is here:

My response to that is here: 

I attached an attempt to recreate the indentation of text/response which got messed up in some versions.

Let's put this on the TAG agenda.

Tim



On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:

   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.


Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.


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


Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.


   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)


If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until


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


A solution would be then to extend the standrad in future versions and code compatibly to that.


   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.


Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time

If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?



   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.


There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.

If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly

   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.

But they have similar technology with their XEnroll API

It is easy to create JS that either uses keygen or Xenroll depending on the browser. Certainly not ideal,
but that's the world we live in.



   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.


Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.




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


The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.





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


I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.

   While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 


What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,




   and represents an authentication scheme that does not work well for the web. 


Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?



   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.


Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.

In the mean time, please fix bugs in client certs which are just a pain.

- Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
- Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.

- In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)

So don't abandon <keygen>, fix it.

And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  

In the meantime please support keygen and improve client cert handling. 

timbl









   [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



Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Wendy Seltzer-3
In reply to this post by Melvin Carvalho
On 09/02/2015 04:06 AM, Melvin Carvalho wrote:

> On 1 September 2015 at 16:08, Tim Berners-Lee <[hidden email]> wrote:
>
>> Folks
>>
>> There is a strong move my Google chrome team followed by Firefox to remove
>> the <keygen> tag from HTML5.   This has been done without an issue being
>> raised in the WHATWG  or HTMLWG apparently.
>>
>> <keygen> is important because it allows authentication systems to be build
>> in a distributed manner. It allows any Mom and Pop shop place to share
>> public keys for people they trust.    For example, MIT uses it to create
>> secure relationship with faculty and staff, and I use it for friends and
>> family.
>>
>> Public key asymmetric crypto is generally so much stronger than the
>> password-based authentication.  It requires certificate management code to
>> be written.
>>
>
> IMHO we need an area of the browser under a user's control

That seems like a different, and more interesting requirement than
"keygen."

Keygen was a poorly designed, inconsistently implemented feature, that
many sophisticated users and developers found confusing. If we can
instead define what features we want to be able to build, and what they
depend on that's not provided by WebCrypto, and think about how we can
enable users to access these features without opening themselves up to
be phished or tracked, that feels like a more productive avenue for
discussion than "bring back keygen".

--Wendy


--
Wendy Seltzer -- [hidden email] +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)


Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Melvin Carvalho


On 2 September 2015 at 14:15, Wendy Seltzer <[hidden email]> wrote:
On 09/02/2015 04:06 AM, Melvin Carvalho wrote:
> On 1 September 2015 at 16:08, Tim Berners-Lee <[hidden email]> wrote:
>
>> Folks
>>
>> There is a strong move my Google chrome team followed by Firefox to remove
>> the <keygen> tag from HTML5.   This has been done without an issue being
>> raised in the WHATWG  or HTMLWG apparently.
>>
>> <keygen> is important because it allows authentication systems to be build
>> in a distributed manner. It allows any Mom and Pop shop place to share
>> public keys for people they trust.    For example, MIT uses it to create
>> secure relationship with faculty and staff, and I use it for friends and
>> family.
>>
>> Public key asymmetric crypto is generally so much stronger than the
>> password-based authentication.  It requires certificate management code to
>> be written.
>>
>
> IMHO we need an area of the browser under a user's control

That seems like a different, and more interesting requirement than
"keygen."



keygen puts a keypair/certificate into an area of the browser (chrome) that is under user control, in the sense that the key material is protected from downloaded javascript, but the user has

- ability to manage the key/certificate (view / import / export)
- ability to choose when this key is used


 

Keygen was a poorly designed, inconsistently implemented feature, that
many sophisticated users and developers found confusing. If we can
instead define what features we want to be able to build, and what they
depend on that's not provided by WebCrypto, and think about how we can
enable users to access these features without opening themselves up to
be phished or tracked, that feels like a more productive avenue for
discussion than "bring back keygen".

I there are good UIs already implemented in most browsers, for example, for sharing location.  Your location is under your control, but you can choose when you want to share it.

Similarly, if keygen were able to 
 

--Wendy


--
Wendy Seltzer -- [hidden email] <a href="tel:%2B1.617.715.4883" value="+16177154883">+1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        <a href="tel:%2B1.617.863.0613" value="+16178630613">+1.617.863.0613 (mobile)


Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Melvin Carvalho
In reply to this post by Wendy Seltzer-3


On 2 September 2015 at 14:15, Wendy Seltzer <[hidden email]> wrote:
On 09/02/2015 04:06 AM, Melvin Carvalho wrote:
> On 1 September 2015 at 16:08, Tim Berners-Lee <[hidden email]> wrote:
>
>> Folks
>>
>> There is a strong move my Google chrome team followed by Firefox to remove
>> the <keygen> tag from HTML5.   This has been done without an issue being
>> raised in the WHATWG  or HTMLWG apparently.
>>
>> <keygen> is important because it allows authentication systems to be build
>> in a distributed manner. It allows any Mom and Pop shop place to share
>> public keys for people they trust.    For example, MIT uses it to create
>> secure relationship with faculty and staff, and I use it for friends and
>> family.
>>
>> Public key asymmetric crypto is generally so much stronger than the
>> password-based authentication.  It requires certificate management code to
>> be written.
>>
>
> IMHO we need an area of the browser under a user's control

That seems like a different, and more interesting requirement than
"keygen."

[sorry gmail sent previous mid flow]

keygen puts a keypair/certificate into an area of the browser (chrome) that is under user control, in the sense that the key material is protected from downloaded javascript, but the user has

- ability to manage the key/certificate (view / import / export)
- ability to choose when this key is used
 

Keygen was a poorly designed, inconsistently implemented feature, that
many sophisticated users and developers found confusing. If we can
instead define what features we want to be able to build, and what they
depend on that's not provided by WebCrypto, and think about how we can
enable users to access these features without opening themselves up to
be phished or tracked, that feels like a more productive avenue for
discussion than "bring back keygen".

I there are good UIs already implemented in most browsers, for example, for sharing location.  Your location is under your control, but you can choose when you want to share it.

Similarly, if keygen were able to do something similar with a keypair and minimal identity atributes e.g.

- public key
- signing a challenge to authenticate
- avatar
- url
- name

Which is a summary of the fields in an X.509 data structure, I think that would be idea.  By giving the user choice of which sites to share their details with, like with location, you prevent some attacks.
 

--Wendy


--
Wendy Seltzer -- [hidden email] <a href="tel:%2B1.617.715.4883" value="+16177154883">+1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        <a href="tel:%2B1.617.863.0613" value="+16178630613">+1.617.863.0613 (mobile)


Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Melvin Carvalho
In reply to this post by Wendy Seltzer-3


On 2 September 2015 at 14:15, Wendy Seltzer <[hidden email]> wrote:
On 09/02/2015 04:06 AM, Melvin Carvalho wrote:
> On 1 September 2015 at 16:08, Tim Berners-Lee <[hidden email]> wrote:
>
>> Folks
>>
>> There is a strong move my Google chrome team followed by Firefox to remove
>> the <keygen> tag from HTML5.   This has been done without an issue being
>> raised in the WHATWG  or HTMLWG apparently.
>>
>> <keygen> is important because it allows authentication systems to be build
>> in a distributed manner. It allows any Mom and Pop shop place to share
>> public keys for people they trust.    For example, MIT uses it to create
>> secure relationship with faculty and staff, and I use it for friends and
>> family.
>>
>> Public key asymmetric crypto is generally so much stronger than the
>> password-based authentication.  It requires certificate management code to
>> be written.
>>
>
> IMHO we need an area of the browser under a user's control

That seems like a different, and more interesting requirement than
"keygen."

Keygen was a poorly designed, inconsistently implemented feature, that
many sophisticated users and developers found confusing. If we can
instead define what features we want to be able to build, and what they
depend on that's not provided by WebCrypto, and think about how we can
enable users to access these features without opening themselves up to
be phished or tracked, that feels like a more productive avenue for
discussion than "bring back keygen".

Looking at the latest Credential Management spec (Sep 2)

This kind of functionality looks quite promising in terms of helping to replace existing functionality
A UI mockup here
But I dont think it's yet in widespread use.
 

--Wendy


--
Wendy Seltzer -- [hidden email] <a href="tel:%2B1.617.715.4883" value="+16177154883">+1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        <a href="tel:%2B1.617.863.0613" value="+16178630613">+1.617.863.0613 (mobile)


Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Henry Story-4
In reply to this post by Henry Story-3
On 2 September 2015 at 16:53, Melvin Carvalho <[hidden email]> wrote:
On 2 September 2015 at 14:15, Wendy Seltzer <[hidden email]> wrote:

> On 09/02/2015 04:06 AM, Melvin Carvalho wrote:
>> On 1 September 2015 at 16:08, Tim Berners-Lee <[hidden email]> wrote:
>>
>>> Folks
>>>
>>> There is a strong move my Google chrome team followed by Firefox to remove
>>> the <keygen> tag from HTML5.   This has been done without an issue being
>>> raised in the WHATWG  or HTMLWG apparently.
>>>
>>> <keygen> is important because it allows authentication systems to be build
>>> in a distributed manner. It allows any Mom and Pop shop place to share
>>> public keys for people they trust.    For example, MIT uses it to create
>>> secure relationship with faculty and staff, and I use it for friends and
>>> family.
>>>
>>> Public key asymmetric crypto is generally so much stronger than the
>>> password-based authentication.  It requires certificate management code
>>> to be written.
>>>
>>
>> IMHO we need an area of the browser under a user's control
>
> That seems like a different, and more interesting requirement than
> "keygen."
>
> Keygen was a poorly designed, inconsistently implemented feature, that
> many sophisticated users and developers found confusing. If we can
> instead define what features we want to be able to build, and what they
> depend on that's not provided by WebCrypto, and think about how we can
> enable users to access these features without opening themselves up to
> be phished or tracked, that feels like a more productive avenue for
> discussion than "bring back keygen".
It would be good to have a well document list of these problems so that 
future designs could make sure they did not re-create them. I have not 
yet found a good evolving document that makes these points clearly. 
This is the problem with removing keygen and other features at this point,
as it is quite likely that a number of diffuse misunderstanding ( not unlikely 
given that we are dealing  with overlap between very different disciplines 
from Cryptography to UserInterface Design and distributed data, betwen Browser 
and Server specialities, political issues such as relations between 
privacy and centralisation) are contributing  to simple answers not being found. 
>

Looking at the latest Credential Management spec (Sep 2)

This kind of functionality looks quite promising in terms of helping to
replace existing functionality

https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection

A UI mockup here

https://w3c.github.io/webappsec/specs/credentialmanagement/mock-chooser.png

But I dont think it's yet in widespread use.

(1) What is needed is a way for the browser to create a public/private key pair, keep the private protected in the browser in such a way that the private key is never accessible or visible to the JS or in any other way, other than perhaps to specific applications under the users control ( which is usually the job of a keychain ). The UI has to make it clear to the user that this is the case. This is what keygen and MS's certificate enrollment JS API also enables [1].
    Not being browser owners we are are obviously not tied to the exact implementation of keygen - though the declarative nature of keygen is perhaps not such a bad idea as it fits with the TAGs finding on the rule of least power [3].

(2) It should be possible for the server to return a certificate using the public-key part it received to form a 
certificate. Currently this was possible by the server returning a X509 Certificate using the application/x-x509-*-cert
mime type ( the same folks wanting deprecate keygen also want to deprecate this). The browser would then find the matching private key and set the certificate in the users certificate store for later authentication to other web sites.
  X509 is an old standard. We are not tied to that. JS equivalents such as the certificate structure proposed by Mozilla
Persona [2] would also be fine. In my view it should be possible for the web server to return a number of different certificates simultaneously in order to allow for a transition period and innovation in the certificate space.

(3) The certicate and public key should allow the user to authenticate using asymetric public key cryptography to any site that he wishes to. Currently this was done using TLS client authentication - which has its problems. For HTTP 2.0 better mechansims need to be invented - but it looks like some tie into TLS is important for security ( the keyword here seems to be HTTP 2.0 channel binding ). As shown in the credentials management document Melvin just pointed to, this requires a User Interface component, keeping the user in charge of authentication and logout. What is missing in the Credentials Management document therefore is a way to authenticate using certificates based on asymetric public key cryptography. 
Note that client certificate managment does not require large centralised and expensive certificate authorities ( expensive because they become liable for untold number of identities ) but can be done in a web of trust manner as shown for example by the WebID specs [4]

All of this is currently possible using keygen, x509 certificates and TLS client authentication. Of course nothing in this space keeps still, and there is always progress. But one cannot avoid tie into to the chrome if one wants the user to be at least aware of what identity he is using on each origin he is going to and in order for him to be able to recognise a phishing attack. This is why this cannot just be done purely at the JS level without tie into the chrome ( It is good to see that the WebApp Sec group agrees with this ).

(4) It would probably be very useful to provide very limited signing APIs that could use this public key material. Of course this would require more UI design work in the chrome. In the security space the rule of least power [3] is more relevant than ever.


    This does not exclude large providers either btw.


>
> --Wendy
>
>
> --
> Wendy Seltzer -- [hidden email] +1.617.715.4883 (office)
> Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
> http://wendy.seltzer.org/        +1.617.863.0613 (mobile)
>

Social Web Architect

Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Harry Halpin
In reply to this post by Tim Berners-Lee
On Tue, Sep 1, 2015 at 10:08 AM, Tim Berners-Lee <[hidden email]> wrote:
Folks

There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.

<keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.

Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.

Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.


It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.

Keygen is not therefore something which you can just code in Javascript. 

The original July 28  announcement from the Chrome team is here:

My response to that is here: 

I attached an attempt to recreate the indentation of text/response which got messed up in some versions.

Let's put this on the TAG agenda.

Tim


TimBL,

It seems the use-case is for people to authenticate securely to web-sites they trust, with the security being done by key material rather than passwords. There is already a standard for that called "FIDO" (Fast IDentity Online) that W3C is already co-operating with, as shown by our workshop final report here:

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html

The specs are open and cover both key-based authentication (although it cleanly separates out identity from authentication and follows the same-origin policy) and multi-factor authentication.

https://fidoalliance.org/specifications/overview/

I know myself, quite a few of W3C Team, and many W3C members are excited by FIDO and, while it is currently being developed in a closed process, the plan is I believe to bring it to an open standards process like IETF and W3C.

If your request is to keep <keygen> *until* FIDO is in browsers, I think that's reasonable, although the user-base of people authenticating with client certificates is quite small. However, it is also reasonable to warn developers that it will be deprecated soon, and that new protocols or products should *not* depend on <keygen>.

There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems. X.509 is also problematic to parse, leading to security issues [2]. While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year.

In terms of your current coding projects that depend on <keygen> and WebID+TLS, I'm sure the larger W3C community would be thrilled to work out solutions for your use-cases based on FIDO - and maybe   OAuth (also not perfect, but possible to be improved to give better privacy/anonymity [3])  -  that use the JOSE specs for key material. This would make the exciting coding projects being done by yourself and others compatible with Web while providing better privacy and security properties that the X.509/TLS stack.

So, perhaps a reasonable compromise is that we can not immediately disable <keygen> until FIDO is implemented in browsers, and then remove it, while warning developers *now.*

    yours,
          harry


 


On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:

   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.


Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.


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


Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.


   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)


If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until


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


A solution would be then to extend the standrad in future versions and code compatibly to that.


   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.


Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time

If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?



   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.


There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.

If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly

   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.


Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.




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


The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.





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


I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.

   While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 


What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,




   and represents an authentication scheme that does not work well for the web. 


Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?



   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.


Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.

In the mean time, please fix bugs in client certs which are just a pain.

- Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
- Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.

- In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)

So don't abandon <keygen>, fix it.

And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  

In the meantime please support keygen and improve client cert handling. 

timbl









   [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



Reply | Threaded
Open this post in threaded view
|

RE: Agenda: <keygen> being destroyed when we need it

SULLIVAN, BRYAN L (ATTCINW)

Harry,

 

FIDO is not a replacement for keygen. It involves multiple entities including some device-native functions that perform key registration etc using biometrics and other options (even SIM-based trusted UIs). It’s a nice concept and is gaining traction, but does have dependencies on functions outside the browser, thus is not a universal solution for key management.

 

Keeping the keygen tag and functions fully supported by browsers (as a standalone capability) is a more broadly viable solution, and I would recommend it.

 

Thanks,

Bryan Sullivan | AT&T

 

From: Harry Halpin [mailto:[hidden email]]
Sent: Wednesday, September 02, 2015 3:25 PM
To: Tim Berners-Lee
Cc: [hidden email]; daniel Appelquist; Linss, Peter; Wendy Setzer
Subject: Re: Agenda: <keygen> being destroyed when we need it

 

On Tue, Sep 1, 2015 at 10:08 AM, Tim Berners-Lee <[hidden email]> wrote:

Folks

 

There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.

 

<keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.

 

Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.

 

Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.

 

 

It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.

 

Keygen is not therefore something which you can just code in Javascript. 

 

The original July 28  announcement from the Chrome team is here:

 

My response to that is here: 

 

I attached an attempt to recreate the indentation of text/response which got messed up in some versions.

 

Let's put this on the TAG agenda.

 

Tim

 

 

TimBL,

 

It seems the use-case is for people to authenticate securely to web-sites they trust, with the security being done by key material rather than passwords. There is already a standard for that called "FIDO" (Fast IDentity Online) that W3C is already co-operating with, as shown by our workshop final report here:

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html

The specs are open and cover both key-based authentication (although it cleanly separates out identity from authentication and follows the same-origin policy) and multi-factor authentication.

https://fidoalliance.org/specifications/overview/

I know myself, quite a few of W3C Team, and many W3C members are excited by FIDO and, while it is currently being developed in a closed process, the plan is I believe to bring it to an open standards process like IETF and W3C.

If your request is to keep <keygen> *until* FIDO is in browsers, I think that's reasonable, although the user-base of people authenticating with client certificates is quite small. However, it is also reasonable to warn developers that it will be deprecated soon, and that new protocols or products should *not* depend on <keygen>.

There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems. X.509 is also problematic to parse, leading to security issues [2]. While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year.

In terms of your current coding projects that depend on <keygen> and WebID+TLS, I'm sure the larger W3C community would be thrilled to work out solutions for your use-cases based on FIDO - and maybe   OAuth (also not perfect, but possible to be improved to give better privacy/anonymity [3])  -  that use the JOSE specs for key material. This would make the exciting coding projects being done by yourself and others compatible with Web while providing better privacy and security properties that the X.509/TLS stack.

So, perhaps a reasonable compromise is that we can not immediately disable <keygen> until FIDO is implemented in browsers, and then remove it, while warning developers *now.*

 

    yours,

          harry


 

 

 

On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:


   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.

Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.



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

Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.


   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)


If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until



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

A solution would be then to extend the standrad in future versions and code compatibly to that.



   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.

Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time

If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?




   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.


There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.

If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly


   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.


Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.




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


The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.






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

I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.


   While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 

What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,





   and represents an authentication scheme that does not work well for the web. 


Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?




   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.


Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.

In the mean time, please fix bugs in client certs which are just a pain.

- Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
- Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.

- In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)

So don't abandon <keygen>, fix it.

And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  

In the meantime please support keygen and improve client cert handling. 

timbl









   [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

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Melvin Carvalho
In reply to this post by Harry Halpin


On 3 September 2015 at 00:25, Harry Halpin <[hidden email]> wrote:
On Tue, Sep 1, 2015 at 10:08 AM, Tim Berners-Lee <[hidden email]> wrote:
Folks

There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.

<keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.

Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.

Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.


It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.

Keygen is not therefore something which you can just code in Javascript. 

The original July 28  announcement from the Chrome team is here:

My response to that is here: 

I attached an attempt to recreate the indentation of text/response which got messed up in some versions.

Let's put this on the TAG agenda.

Tim


TimBL,

It seems the use-case is for people to authenticate securely to web-sites they trust, with the security being done by key material rather than passwords. There is already a standard for that called "FIDO" (Fast IDentity Online) that W3C is already co-operating with, as shown by our workshop final report here:

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html

The specs are open and cover both key-based authentication (although it cleanly separates out identity from authentication and follows the same-origin policy) and multi-factor authentication.

https://fidoalliance.org/specifications/overview/

I know myself, quite a few of W3C Team, and many W3C members are excited by FIDO and, while it is currently being developed in a closed process, the plan is I believe to bring it to an open standards process like IETF and W3C.

If your request is to keep <keygen> *until* FIDO is in browsers, I think that's reasonable, although the user-base of people authenticating with client certificates is quite small. However, it is also reasonable to warn developers that it will be deprecated soon, and that new protocols or products should *not* depend on <keygen>.

There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems.

Thanks for providing this link.  You mention "several" high profile attacks, tho I only saw one attack.  How many others are you aware of?

For attack you mention it said that fixes had been applied to : Chrome, Opera, Android, IE, Firefox, Safari, IOS, OpenSSL, GNUTLS, Java and others.

Are there some other systems you are concerned about?  Do you have any stats of prevalence of this attack in the wild?

For example, for the use case of dealing with trusted family members for collaboration, I think we can rule out the malicious server problem, more likely would just be to come over to your computer and access it physically :)
 
X.509 is also problematic to parse, leading to security issues [2]. While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year.

In terms of your current coding projects that depend on <keygen> and WebID+TLS, I'm sure the larger W3C community would be thrilled to work out solutions for your use-cases based on FIDO - and maybe   OAuth (also not perfect, but possible to be improved to give better privacy/anonymity [3])  -  that use the JOSE specs for key material. This would make the exciting coding projects being done by yourself and others compatible with Web while providing better privacy and security properties that the X.509/TLS stack.

So, perhaps a reasonable compromise is that we can not immediately disable <keygen> until FIDO is implemented in browsers, and then remove it, while warning developers *now.*

    yours,
          harry


 


On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:

   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.


Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.


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


Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.


   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)


If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until


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


A solution would be then to extend the standrad in future versions and code compatibly to that.


   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.


Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time

If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?



   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.


There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.

If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly

   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.


Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.




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


The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.





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


I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.

   While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 


What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,




   and represents an authentication scheme that does not work well for the web. 


Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?



   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.


Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.

In the mean time, please fix bugs in client certs which are just a pain.

- Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
- Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.

- In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)

So don't abandon <keygen>, fix it.

And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  

In the meantime please support keygen and improve client cert handling. 

timbl









   [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




Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Henry Story-3
In reply to this post by Harry Halpin

On 3 Sep 2015, at 00:25, Harry Halpin <[hidden email]> wrote:

On Tue, Sep 1, 2015 at 10:08 AM, Tim Berners-Lee <[hidden email]> wrote:
Folks

There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.

<keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.

Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.

Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.


It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.

Keygen is not therefore something which you can just code in Javascript. 

The original July 28  announcement from the Chrome team is here:

My response to that is here: 

I attached an attempt to recreate the indentation of text/response which got messed up in some versions.

Let's put this on the TAG agenda.

Tim


TimBL, 

It seems the use-case is for people to authenticate securely to web-sites they trust, with the security being done by key material rather than passwords. There is already a standard for that called "FIDO" (Fast IDentity Online) that W3C is already co-operating with, as shown by our workshop final report here:

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html

The specs are open and cover both key-based authentication (although it cleanly separates out identity from authentication and follows the same-origin policy) and multi-factor authentication. 

https://fidoalliance.org/specifications/overview/

I know myself, quite a few of W3C Team, and many W3C members are excited by FIDO and, while it is currently being developed in a closed process, the plan is I believe to bring it to an open standards process like IETF and W3C. 

If your request is to keep <keygen> *until* FIDO is in browsers, I think that's reasonable, although the user-base of people authenticating with client certificates is quite small. However, it is also reasonable to warn developers that it will be deprecated soon, and that new protocols or products should *not* depend on <keygen>.

There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems.

This is a man in the middle attack and has no reference to X509. Furthermore it has already been patched the most widely used browsers and libraries. 

All security protocols are constantly under review and improvement: security is by necessity a wholistic project which needs to take into consideration all layers including social and psychological ones. Last year's Web Crypto Workshop report you mentioned states that "for example replay attacks on certain layers (SMS) present security problems". That is not an argument to remove that channel, but presumably to improve it.

X.509 is also problematic to parse, leading to security issues [2].

That is a 2010 paper by Dan Kaminsky and al. He talked about this at length at various hacker conferences one of which I was present at some 4 years ago or so. The paper contains suggestions
for fixes which I were presumably implemented in the mean time. 

<aside>
I was of course listening intently to his talk, as I was worried enough about this for WebID+TLS. 
So I caught him after the talk and presented him the idea of WebID+TLS in a 1 minute 
( it's really that easy ). He loved the idea and in fact defended it right there and then as it
echoed some ideas he had regarding how to improve server security using DNSSEC.
A few months later the IETF started the DANE project which is pretty much the
WebID logic applied to servers instead of clients ( ie, instead of publishing a public key 
for a certificate on the Web, DANE publishes it in DNSSEC for the server ).
</aside>

X.509 is indeed legacy that is difficult to deprecate as it so so widely deployed on the web. But TLS is in fact extensible as far as certificate encoding goes. There is even an RFC "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication" https://tools.ietf.org/html/rfc6091
One could also write one that used the same JSON format that was used by the Mozilla Persona
project, or even JOSE  ( https://datatracker.ietf.org/wg/jose/charter/ )
This would not change the semantics of TLS, just make it easier to code certificates presumably, extend them, and for them to be less prone to those bugs listed by Kaminsky that are due to the numerous ways of encoding numbers.
   For client authentication I can see that moving to a JOSE based certificate would be the first step
before making changes on the server side. But this will mean a transition period where browsers will
need to hold two versions of a same certificate for a given public/privte key.

While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year. 

In terms of your current coding projects that depend on <keygen> and WebID+TLS, I'm sure the larger W3C community would be thrilled to work out solutions for your use-cases based on FIDO - and maybe   OAuth (also not perfect, but possible to be improved to give better privacy/anonymity [3])  -  that use the JOSE specs for key material. This would make the exciting coding projects being done by yourself and others compatible with Web while providing better privacy and security properties that the X.509/TLS stack. 

(1) In order to enable the browser to authenticate to any site (even ones the user has never visted before) without going through a third "Authentication provider", asymetric key cryptography and some encoding of a certificate ( however minimal), is required. 
-> This means the browser has to be able to generate a public/private key pair, and get the public key published somewhere. Ie. it needs a <keygen> like functionality, and a way to associate extra information to the key via some certificate format. 

(2) There then needs to be a protocol at the HTTP layer ( together presumably with TLS to avoid man in the middle attacks ), that enables the server to ask the client for authentication to access a resource. The client must be able to pass this request on to the user in such a way that it is impossible to phish the interface. ( presumably using some of the tools from the FIDO tool box - such as fingerprinting,etc. )
If the user accepts the authentication, the client must be able to use the private key material at its disposal
in a way that it does not leak, in order to authenticate the user. 
-> This is currently made possible by TLS client certificate authentication, but there are other proposals on the table that would adapt this so that it fits better with HTTP2.0. See the discussion started on the IETF HTTP mailing list

(3) The client needs to be able aware of the persona he is using at any time and be able to log out at any moment if needed. ( privacy requirement )
   This is a User Interface/Chrome requirement that requires UI designers, something along the lines
of what is proposed by the WebAppSec WG.

These pieces work in current browsers.In the WebID XG we just used the technology that actually existed in browsers (as we are not browser vendors but application developers) to get all of this working.
It is very powerful. But we welcome improvements to the technology at all levels. 

It is clear though that the functionality provided by keygen, certificates and authentication using asymetric public keys will continue to be needed if we want to build a secure distributed decentralised web where each all can participate as free citizens.

So, perhaps a reasonable compromise is that we can not immediately disable <keygen> until FIDO is implemented in browsers, and then remove it, while warning developers *now.*

We should definitively look at what FIDO provides. But it is not clear yet that it provides what is being taken away. In fact in this thread Bryan Sullivan has stated that it does not. Until this is absolutely clear one should not jump to conclusions. 

    yours,
          harry


 


On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:

   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.


Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.


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


Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.


   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)


If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until


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


A solution would be then to extend the standrad in future versions and code compatibly to that.


   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.


Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time

If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?



   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.


There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.

If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly

   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.


Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.




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


The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.





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


I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.

   While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 


What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,




   and represents an authentication scheme that does not work well for the web. 


Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?



   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.


Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.

In the mean time, please fix bugs in client certs which are just a pain.

- Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
- Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.

- In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)

So don't abandon <keygen>, fix it.

And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  

In the meantime please support keygen and improve client cert handling. 

timbl









   [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

Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Anders Rundgren-2
Henry,

Since the whole "https everywhere" thing builds on the use of x.509 certificates
there can hardly be a unresolvable format issue here.

The problem is really that the (by far) leading provider of desktop OSes is
(and has always been), completely uninterested in users of x.509 client-
certificates outside of the enterprise (rather the USG), which unfortunately
makes x.509 client-certificates a poor choice.

An example: If you insert a blank PKI-card in a desktop computer, typically
nothing happens. FIDO Alliance products OTOH work (will at least)
"out-of-the-box" and do not depend on obscure third-parties supplying
"card-drivers". The latter has from my experience proved to be unworkable
except for very deep-pocketed organizations who can afford hiring s.c.
"smart card experts" who knows exactly which OS, card and driver-version that works.

There's nothing we can do about this. Some really big users of x.509 client-
certificates have solved their problem by turning to "Apps" rather than Web.
These users are NOT in the USA.

Anders
On 2015-09-03 16:10, Henry Story wrote:

>
>> On 3 Sep 2015, at 00:25, Harry Halpin <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> On Tue, Sep 1, 2015 at 10:08 AM, Tim Berners-Lee<[hidden email] <mailto:[hidden email]>>wrote:
>>
>>     Folks
>>
>>     There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.
>>
>>     <keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.
>>
>>     Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.
>>
>>     Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.
>>
>>
>>     It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.
>>
>>     Keygen is not therefore something which you can just code in Javascript.
>>
>>     The original July 28  announcement from the Chrome team is here:
>>     https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack/discussion
>>
>>     My response to that is here:
>>     https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/5CQnw56-BQAJ
>>
>>     I attached an attempt to recreate the indentation of text/response which got messed up in some versions.
>>
>>     Let's put this on the TAG agenda.
>>
>>     Tim
>>
>>
>> TimBL,
>>
>> It seems the use-case is for people to authenticate securely to web-sites they trust, with the security being done by key material rather than passwords. There is already a standard for that called "FIDO" (Fast IDentity Online) that W3C is already co-operating with, as shown by our workshop final report here:
>>
>> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html
>>
>> The specs are open and cover both key-based authentication (although it cleanly separates out identity from authentication and follows the same-origin policy) and multi-factor authentication.
>>
>> https://fidoalliance.org/specifications/overview/
>>
>> I know myself, quite a few of W3C Team, and many W3C members are excited by FIDO and, while it is currently being developed in a closed process, the plan is I believe to bring it to an open standards process like IETF and W3C.
>>
>> If your request is to keep <keygen> *until* FIDO is in browsers, I think that's reasonable, although the user-base of people authenticating with client certificates is quite small. However, it is also reasonable to warn developers that it will be deprecated soon, and that new protocols or products should *not* depend on <keygen>.
>>
>> There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems.
>
> This is a man in the middle attack and has no reference to X509. Furthermore it has already been patched the most widely used browsers and libraries.
>
> All security protocols are constantly under review and improvement: security is by necessity a wholistic project which needs to take into consideration all layers including social and psychological ones. Last year's Web Crypto Workshop report you mentioned states that "for example replay attacks on certain layers (SMS) present security problems". That is not an argument to remove that channel, but presumably to improve it.
>
>> X.509 is also problematic to parse, leading to security issues [2].
>
> That is a 2010 paper by Dan Kaminsky and al. He talked about this at length at various hacker conferences one of which I was present at some 4 years ago or so. The paper contains suggestions
> for fixes which I were presumably implemented in the mean time.
>
> <aside>
> I was of course listening intently to his talk, as I was worried enough about this for WebID+TLS.
> So I caught him after the talk and presented him the idea of WebID+TLS in a 1 minute
> ( it's really that easy ). He loved the idea and in fact defended it right there and then as it
> echoed some ideas he had regarding how to improve server security using DNSSEC.
> A few months later the IETF started the DANE project which is pretty much the
> WebID logic applied to servers instead of clients ( ie, instead of publishing a public key
> for a certificate on the Web, DANE publishes it in DNSSEC for the server ).
> https://datatracker.ietf.org/wg/dane/charter/
> </aside>
>
> X.509 is indeed legacy that is difficult to deprecate as it so so widely deployed on the web. But TLS is in fact extensible as far as certificate encoding goes. There is even an RFC "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication" https://tools.ietf.org/html/rfc6091
> One could also write one that used the same JSON format that was used by the Mozilla Persona
> project, or even JOSE  ( https://datatracker.ietf.org/wg/jose/charter/ )
> This would not change the semantics of TLS, just make it easier to code certificates presumably, extend them, and for them to be less prone to those bugs listed by Kaminsky that are due to the numerous ways of encoding numbers.
>     For client authentication I can see that moving to a JOSE based certificate would be the first step
> before making changes on the server side. But this will mean a transition period where browsers will
> need to hold two versions of a same certificate for a given public/privte key.
>
>> While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year.
>>
>> In terms of your current coding projects that depend on <keygen> and WebID+TLS, I'm sure the larger W3C community would be thrilled to work out solutions for your use-cases based on FIDO - and maybe   OAuth (also not perfect, but possible to be improved to give better privacy/anonymity [3])  -  that use the JOSE specs for key material. This would make the exciting coding projects being done by yourself and others compatible with Web while providing better privacy and security properties that the X.509/TLS stack.
>
> (1) In order to enable the browser to authenticate to any site (even ones the user has never visted before) without going through a third "Authentication provider", asymetric key cryptography and some encoding of a certificate ( however minimal), is required.
> -> This means the browser has to be able to generate a public/private key pair, and get the public key published somewhere. Ie. it needs a <keygen> like functionality, and a way to associate extra information to the key via some certificate format.
>
> (2) There then needs to be a protocol at the HTTP layer ( together presumably with TLS to avoid man in the middle attacks ), that enables the server to ask the client for authentication to access a resource. The client must be able to pass this request on to the user in such a way that it is impossible to phish the interface. ( presumably using some of the tools from the FIDO tool box - such as fingerprinting,etc. )
> If the user accepts the authentication, the client must be able to use the private key material at its disposal
> in a way that it does not leak, in order to authenticate the user.
> -> This is currently made possible by TLS client certificate authentication, but there are other proposals on the table that would adapt this so that it fits better with HTTP2.0. See the discussion started on the IETF HTTP mailing list
> https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0558.html
>
> (3) The client needs to be able aware of the persona he is using at any time and be able to log out at any moment if needed. ( privacy requirement )
>     This is a User Interface/Chrome requirement that requires UI designers, something along the lines
> of what is proposed by the WebAppSec WG.
>
> These pieces work in current browsers.In the WebID XG we just used the technology that actually existed in browsers (as we are not browser vendors but application developers) to get all of this working.
> It is very powerful. But we welcome improvements to the technology at all levels.
>
> It is clear though that the functionality provided by keygen, certificates and authentication using asymetric public keys will continue to be needed if we want to build a secure distributed decentralised web where each all can participate as free citizens.
>
>> So, perhaps a reasonable compromise is that we can not immediately disable <keygen> until FIDO is implemented in browsers, and then remove it, while warning developers *now.*
>
> We should definitively look at what FIDO provides. But it is not clear yet that it provides what is being taken away. In fact in this thread Bryan Sullivan has stated that it does not. Until this is absolutely clear one should not jump to conclusions.
>
>>     yours,
>>           harry
>>
>> [1]https://www.secure-resumption.com/
>> [2]https://www.cosic.esat.kuleuven.be/publications/article-1432.pdf
>> [3]http://www.degruyter.com/view/j/popets.2015.2015.issue-2/popets-2015-0022/popets-2015-0022.xml
>>
>>
>>
>>
>>     On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:
>>
>>>        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.
>>>
>>>
>>     Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.
>>
>>>
>>>        [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]
>>>
>>>
>>     Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.
>>
>>
>>        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)
>>
>>
>>     If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until
>>
>>>
>>>        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])
>>>
>>>
>>     A solution would be then to extend the standrad in future versions and code compatibly to that.
>>
>>
>>>        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.
>>>
>>>
>>     Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time
>>
>>     If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?
>>
>>
>>
>>>        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.
>>>
>>
>>     There is a typical browser vendor mindset: this feature allows a web site to do something to the user.
>>     Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.
>>
>>     If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly
>>
>>>        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.
>>>
>>>
>>>     Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.
>>>
>>>
>>>
>>>
>>>        [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.
>>>
>>
>>     The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.
>>
>>
>>
>>
>>>
>>>        On some level, this removal will remove support for arbitrarily adding keys to the users' device-wide store, which is an intentional, by-design behavior.
>>>
>>>
>>     I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.
>>
>>>        While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability,
>>>
>>>
>>     What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,
>>
>>
>>
>>>
>>>        and represents an authentication scheme that does not work well for the web.
>>>
>>
>>     Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?
>>
>>
>>
>>>        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.
>>>
>>
>>     Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.
>>
>>     In the mean time, please fix bugs in client certs which are just a pain.
>>
>>     - Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
>>     - Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.
>>
>>     - In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)
>>
>>     So don't abandon <keygen>, fix it.
>>
>>     And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.
>>
>>     In the meantime please support keygen and improve client cert handling.
>>
>>     timbl
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>        [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
>


Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Henry Story-3
In reply to this post by Wendy Seltzer-3

> On 2 Sep 2015, at 14:15, Wendy Seltzer <[hidden email]> wrote:
>
> On 09/02/2015 04:06 AM, Melvin Carvalho wrote:
>> On 1 September 2015 at 16:08, Tim Berners-Lee <[hidden email]> wrote:
>>
>>> Folks
>>>
>>> There is a strong move my Google chrome team followed by Firefox to remove
>>> the <keygen> tag from HTML5.   This has been done without an issue being
>>> raised in the WHATWG  or HTMLWG apparently.
>>>
>>> <keygen> is important because it allows authentication systems to be build
>>> in a distributed manner. It allows any Mom and Pop shop place to share
>>> public keys for people they trust.    For example, MIT uses it to create
>>> secure relationship with faculty and staff, and I use it for friends and
>>> family.
>>>
>>> Public key asymmetric crypto is generally so much stronger than the
>>> password-based authentication.  It requires certificate management code to
>>> be written.
>>>
>>
>> IMHO we need an area of the browser under a user's control
>
> That seems like a different, and more interesting requirement than
> "keygen."
>
> Keygen was a poorly designed, inconsistently implemented feature, that
> many sophisticated users and developers found confusing. If we can
> instead define what features we want to be able to build, and what they
> depend on that's not provided by WebCrypto, and think about how we can
> enable users to access these features without opening themselves up to
> be phished or tracked, that feels like a more productive avenue for
> discussion than "bring back keygen".

I think this is much too harsh on keygen btw. What is happening may be
that the documentation in the HTML5 was not good enough at explaining how
it worked. After a discussion on the WhatWG where one key argument against
keygen turned out that it was insecure because of its use of MD5, and after an off
list pointer to what the aleged reason of the problem was I wrote a detailed
response to the WHATWG showing that MD5 has no effect on keygen, and
ansuggesting that improved wording of the spec may help diffuse this
misunderstanding.
 
   https://github.com/whatwg/html/issues/102

This did not stop the issue being closed within 15 minutes of my opening the
issue. ( and I seem to be filterd now on the WHATWG mailing list ).

Henry
 

>
> --Wendy
>
>
> --
> Wendy Seltzer -- [hidden email] +1.617.715.4883 (office)
> Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
> http://wendy.seltzer.org/        +1.617.863.0613 (mobile)


Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Brad Hill
In reply to this post by SULLIVAN, BRYAN L (ATTCINW)
This is not true.  FIDO is origin-bound and point-to-point.  There are no third parties required – much less so than certificates in the general case.  I like to say that FIDO is "PKI without the I".

Biometrics, etc. are completely abstracted away from the on-the-wire protocol.  There is an ability with FIDO to provide device metadata, and to attest that metadata at key registration time with device-class certificates (shared among all devices of a given type to preserve anonymity) but those are strictly optional parts of the protocols.  

Browsers can very easily build a software-only, unattested FIDO authenticator to complement their password managers in just a few hundred lines of code, with absolutely no third parties involved.  I know because I've done it.

-Brad Hill

From: "SULLIVAN, BRYAN L"
Date: Wednesday, September 2, 2015 at 4:03 PM
To: Harry Halpin, Tim Berners-Lee
Cc: "[hidden email]", daniel Appelquist, "Linss, Peter", Wendy Setzer
Subject: RE: Agenda: <keygen> being destroyed when we need it
Resent-From: <[hidden email]>
Resent-Date: Wednesday, September 2, 2015 at 4:04 PM

Harry,

 

FIDO is not a replacement for keygen. It involves multiple entities including some device-native functions that perform key registration etc using biometrics and other options (even SIM-based trusted UIs). It’s a nice concept and is gaining traction, but does have dependencies on functions outside the browser, thus is not a universal solution for key management.

 

Keeping the keygen tag and functions fully supported by browsers (as a standalone capability) is a more broadly viable solution, and I would recommend it.

 

Thanks,

Bryan Sullivan | AT&T

 

From: Harry Halpin [[hidden email]]
Sent: Wednesday, September 02, 2015 3:25 PM
To: Tim Berners-Lee
Cc: [hidden email]; daniel Appelquist; Linss, Peter; Wendy Setzer
Subject: Re: Agenda: <keygen> being destroyed when we need it

 

On Tue, Sep 1, 2015 at 10:08 AM, Tim Berners-Lee <[hidden email]> wrote:

Folks

 

There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.

 

<keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.

 

Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.

 

Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.

 

 

It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.

 

Keygen is not therefore something which you can just code in Javascript. 

 

The original July 28  announcement from the Chrome team is here:

 

My response to that is here: 

 

I attached an attempt to recreate the indentation of text/response which got messed up in some versions.

 

Let's put this on the TAG agenda.

 

Tim

 

 

TimBL,

 

It seems the use-case is for people to authenticate securely to web-sites they trust, with the security being done by key material rather than passwords. There is already a standard for that called "FIDO" (Fast IDentity Online) that W3C is already co-operating with, as shown by our workshop final report here:

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html

The specs are open and cover both key-based authentication (although it cleanly separates out identity from authentication and follows the same-origin policy) and multi-factor authentication.

https://fidoalliance.org/specifications/overview/

I know myself, quite a few of W3C Team, and many W3C members are excited by FIDO and, while it is currently being developed in a closed process, the plan is I believe to bring it to an open standards process like IETF and W3C.

If your request is to keep <keygen> *until* FIDO is in browsers, I think that's reasonable, although the user-base of people authenticating with client certificates is quite small. However, it is also reasonable to warn developers that it will be deprecated soon, and that new protocols or products should *not* depend on <keygen>.

There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems. X.509 is also problematic to parse, leading to security issues [2]. While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year.

In terms of your current coding projects that depend on <keygen> and WebID+TLS, I'm sure the larger W3C community would be thrilled to work out solutions for your use-cases based on FIDO - and maybe   OAuth (also not perfect, but possible to be improved to give better privacy/anonymity [3])  -  that use the JOSE specs for key material. This would make the exciting coding projects being done by yourself and others compatible with Web while providing better privacy and security properties that the X.509/TLS stack.

So, perhaps a reasonable compromise is that we can not immediately disable <keygen> until FIDO is implemented in browsers, and then remove it, while warning developers *now.*

 

    yours,

          harry


 

 

 

On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:


   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.

Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.



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

Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.


   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)


If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until



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

A solution would be then to extend the standrad in future versions and code compatibly to that.



   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.

Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time

If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?




   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.


There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.

If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly


   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.


Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.




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


The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.






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

I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.


   While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 

What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,





   and represents an authentication scheme that does not work well for the web. 


Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?




   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.


Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.

In the mean time, please fix bugs in client certs which are just a pain.

- Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
- Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.

- In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)

So don't abandon <keygen>, fix it.

And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  

In the meantime please support keygen and improve client cert handling. 

timbl









   [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

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Kingsley Idehen
In reply to this post by Harry Halpin
On 9/2/15 6:25 PM, Harry Halpin wrote:
> If your request is to keep <keygen> *until* FIDO is in browsers, I
> think that's reasonable, although the user-base of people
> authenticating with client certificates is quite small. However, it is
> also reasonable to warn developers that it will be deprecated soon,
> and that new protocols or products should *not* depend on <keygen>.

Harry,

Why does it have to be one or the other? Choice is fundamental to any
pursuit of openness.

Let users and/or developers choose their preferences from a pool of
choices.

--
Regards,

Kingsley Idehen      
Founder & CEO
OpenLink Software    
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this



smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Anders Rundgren-2
In reply to this post by Harry Halpin
On 2015-09-03 00:25, Harry Halpin wrote:
<snip>

> If your request is to keep <keygen> *until* FIDO is in browsers,
 > I think that's reasonable, although the user-base of people authenticating
 > with client certificates is quite small.

Where did you get this information?

40% of the Swedish population (yes, Sweden is a small country) have a BankID
which they use quite frequently with multiple public sector providers.

But I guess that since they were pushed-off the Web due to the deprecation of
plugins they shouldn't count anymore...  Fortunately the "App" world marches on!!!

Any takers from other countries and communities?

Anders



Reply | Threaded
Open this post in threaded view
|

RE: Agenda: <keygen> being destroyed when we need it

SULLIVAN, BRYAN L (ATTCINW)
In reply to this post by Brad Hill

By “multiple entities” I mean software functions outside the browser, not third parties (as in sites or OAuth providers etc), although those browser-external software functions are key AFAIK to the value proposition of FIDO’s UAF and U2F selling-points. Focusing only on the over-the-wire protocol, with device metadata (I guess this means fingerprinting source data), may provide some standalone value under FIDO but that is not (again, AFAICT) how the user experience of FIDO is primarily marketed.

 

Thanks,

Bryan Sullivan | AT&T

 

From: Brad Hill [mailto:[hidden email]]
Sent: Friday, September 04, 2015 10:12 AM
To: SULLIVAN, BRYAN L; Harry Halpin; Tim Berners-Lee
Cc: [hidden email]; daniel Appelquist; Linss, Peter; Wendy Setzer
Subject: Re: Agenda: <keygen> being destroyed when we need it

 

This is not true.  FIDO is origin-bound and point-to-point.  There are no third parties required – much less so than certificates in the general case.  I like to say that FIDO is "PKI without the I".

 

Biometrics, etc. are completely abstracted away from the on-the-wire protocol.  There is an ability with FIDO to provide device metadata, and to attest that metadata at key registration time with device-class certificates (shared among all devices of a given type to preserve anonymity) but those are strictly optional parts of the protocols.  

 

Browsers can very easily build a software-only, unattested FIDO authenticator to complement their password managers in just a few hundred lines of code, with absolutely no third parties involved.  I know because I've done it.

 

-Brad Hill

 

From: "SULLIVAN, BRYAN L"
Date: Wednesday, September 2, 2015 at 4:03 PM
To: Harry Halpin, Tim Berners-Lee
Cc: "[hidden email]", daniel Appelquist, "Linss, Peter", Wendy Setzer
Subject: RE: Agenda: <keygen> being destroyed when we need it
Resent-From: <[hidden email]>
Resent-Date: Wednesday, September 2, 2015 at 4:04 PM

 

Harry,

 

FIDO is not a replacement for keygen. It involves multiple entities including some device-native functions that perform key registration etc using biometrics and other options (even SIM-based trusted UIs). It’s a nice concept and is gaining traction, but does have dependencies on functions outside the browser, thus is not a universal solution for key management.

 

Keeping the keygen tag and functions fully supported by browsers (as a standalone capability) is a more broadly viable solution, and I would recommend it.

 

Thanks,

Bryan Sullivan | AT&T

 

From: Harry Halpin [[hidden email]]
Sent: Wednesday, September 02, 2015 3:25 PM
To: Tim Berners-Lee
Cc: [hidden email]; daniel Appelquist; Linss, Peter; Wendy Setzer
Subject: Re: Agenda: <keygen> being destroyed when we need it

 

On Tue, Sep 1, 2015 at 10:08 AM, Tim Berners-Lee <[hidden email]> wrote:

Folks

 

There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.

 

<keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.

 

Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.

 

Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.

 

 

It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.

 

Keygen is not therefore something which you can just code in Javascript. 

 

The original July 28  announcement from the Chrome team is here:

 

My response to that is here: 

 

I attached an attempt to recreate the indentation of text/response which got messed up in some versions.

 

Let's put this on the TAG agenda.

 

Tim

 

 

TimBL,

 

It seems the use-case is for people to authenticate securely to web-sites they trust, with the security being done by key material rather than passwords. There is already a standard for that called "FIDO" (Fast IDentity Online) that W3C is already co-operating with, as shown by our workshop final report here:

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html

The specs are open and cover both key-based authentication (although it cleanly separates out identity from authentication and follows the same-origin policy) and multi-factor authentication.

https://fidoalliance.org/specifications/overview/

I know myself, quite a few of W3C Team, and many W3C members are excited by FIDO and, while it is currently being developed in a closed process, the plan is I believe to bring it to an open standards process like IETF and W3C.

If your request is to keep <keygen> *until* FIDO is in browsers, I think that's reasonable, although the user-base of people authenticating with client certificates is quite small. However, it is also reasonable to warn developers that it will be deprecated soon, and that new protocols or products should *not* depend on <keygen>.

There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems. X.509 is also problematic to parse, leading to security issues [2]. While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year.

In terms of your current coding projects that depend on <keygen> and WebID+TLS, I'm sure the larger W3C community would be thrilled to work out solutions for your use-cases based on FIDO - and maybe   OAuth (also not perfect, but possible to be improved to give better privacy/anonymity [3])  -  that use the JOSE specs for key material. This would make the exciting coding projects being done by yourself and others compatible with Web while providing better privacy and security properties that the X.509/TLS stack.

So, perhaps a reasonable compromise is that we can not immediately disable <keygen> until FIDO is implemented in browsers, and then remove it, while warning developers *now.*

 

    yours,

          harry


 

 

 

On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:



   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.


Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.




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


Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.


   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)


If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until




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


A solution would be then to extend the standrad in future versions and code compatibly to that.




   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.


Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time

If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?





   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.


There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.

If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly



   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.


Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.




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


The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.







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


I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.



   While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 


What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,






   and represents an authentication scheme that does not work well for the web. 


Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?





   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.


Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.

In the mean time, please fix bugs in client certs which are just a pain.

- Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
- Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.

- In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)

So don't abandon <keygen>, fix it.

And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  

In the meantime please support keygen and improve client cert handling. 

timbl









   [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

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Agenda: <keygen> being destroyed when we need it

Brad Hill
Optional features get marketed, but that doesn't make it any more accurate to claim that they are mandatory.

Many sites (and users) find it valuable to be able to connect to FIDO authenticator implementations outside the browser for a variety of reasons (key portability, hardware key protection, multi-factor authentication affordances) but it can be implemented completely inside the browser, just without these bells and whistles.  This is no different from say, the ability to implement client-certificates using a strictly browser-local certificate store vs. a government e-ID smart card with a device-class identifying OID and PIN.  And in that sense <keygen> is, in practice, no less dependent on software functions / entities outside the browser.  

If you want a universal solution for key management with no external dependencies, there is WebCrypto, which combines quite nicely with PKI.js for certificate issuance.  As soon as you need more than that, you're talking about "multiple entities".

From: "SULLIVAN, BRYAN L" <[hidden email]>
Date: Friday, September 4, 2015 at 5:04 PM
To: Bradley Hill <[hidden email]>, Harry Halpin <[hidden email]>, Tim Berners-Lee <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, daniel Appelquist <[hidden email]>, "Linss, Peter" <[hidden email]>, Wendy Setzer <[hidden email]>
Subject: RE: Agenda: <keygen> being destroyed when we need it

By “multiple entities” I mean software functions outside the browser, not third parties (as in sites or OAuth providers etc), although those browser-external software functions are key AFAIK to the value proposition of FIDO’s UAF and U2F selling-points. Focusing only on the over-the-wire protocol, with device metadata (I guess this means fingerprinting source data), may provide some standalone value under FIDO but that is not (again, AFAICT) how the user experience of FIDO is primarily marketed.

 

Thanks,

Bryan Sullivan | AT&T

 

From: Brad Hill [[hidden email]]
Sent: Friday, September 04, 2015 10:12 AM
To: SULLIVAN, BRYAN L; Harry Halpin; Tim Berners-Lee
Cc: [hidden email]; daniel Appelquist; Linss, Peter; Wendy Setzer
Subject: Re: Agenda: <keygen> being destroyed when we need it

 

This is not true.  FIDO is origin-bound and point-to-point.  There are no third parties required – much less so than certificates in the general case.  I like to say that FIDO is "PKI without the I".

 

Biometrics, etc. are completely abstracted away from the on-the-wire protocol.  There is an ability with FIDO to provide device metadata, and to attest that metadata at key registration time with device-class certificates (shared among all devices of a given type to preserve anonymity) but those are strictly optional parts of the protocols.  

 

Browsers can very easily build a software-only, unattested FIDO authenticator to complement their password managers in just a few hundred lines of code, with absolutely no third parties involved.  I know because I've done it.

 

-Brad Hill

 

From: "SULLIVAN, BRYAN L"
Date: Wednesday, September 2, 2015 at 4:03 PM
To: Harry Halpin, Tim Berners-Lee
Cc: "[hidden email]", daniel Appelquist, "Linss, Peter", Wendy Setzer
Subject: RE: Agenda: <keygen> being destroyed when we need it
Resent-From: <[hidden email]>
Resent-Date: Wednesday, September 2, 2015 at 4:04 PM

 

Harry,

 

FIDO is not a replacement for keygen. It involves multiple entities including some device-native functions that perform key registration etc using biometrics and other options (even SIM-based trusted UIs). It’s a nice concept and is gaining traction, but does have dependencies on functions outside the browser, thus is not a universal solution for key management.

 

Keeping the keygen tag and functions fully supported by browsers (as a standalone capability) is a more broadly viable solution, and I would recommend it.

 

Thanks,

Bryan Sullivan | AT&T

 

From: Harry Halpin [[hidden email]]
Sent: Wednesday, September 02, 2015 3:25 PM
To: Tim Berners-Lee
Cc: [hidden email]; daniel Appelquist; Linss, Peter; Wendy Setzer
Subject: Re: Agenda: <keygen> being destroyed when we need it

 

On Tue, Sep 1, 2015 at 10:08 AM, Tim Berners-Lee <[hidden email]> wrote:

Folks

 

There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.

 

<keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.

 

Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.

 

Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.

 

 

It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.

 

Keygen is not therefore something which you can just code in Javascript. 

 

The original July 28  announcement from the Chrome team is here:

 

My response to that is here: 

 

I attached an attempt to recreate the indentation of text/response which got messed up in some versions.

 

Let's put this on the TAG agenda.

 

Tim

 

 

TimBL,

 

It seems the use-case is for people to authenticate securely to web-sites they trust, with the security being done by key material rather than passwords. There is already a standard for that called "FIDO" (Fast IDentity Online) that W3C is already co-operating with, as shown by our workshop final report here:

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html

The specs are open and cover both key-based authentication (although it cleanly separates out identity from authentication and follows the same-origin policy) and multi-factor authentication.

https://fidoalliance.org/specifications/overview/

I know myself, quite a few of W3C Team, and many W3C members are excited by FIDO and, while it is currently being developed in a closed process, the plan is I believe to bring it to an open standards process like IETF and W3C.

If your request is to keep <keygen> *until* FIDO is in browsers, I think that's reasonable, although the user-base of people authenticating with client certificates is quite small. However, it is also reasonable to warn developers that it will be deprecated soon, and that new protocols or products should *not* depend on <keygen>.

There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems. X.509 is also problematic to parse, leading to security issues [2]. While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year.

In terms of your current coding projects that depend on <keygen> and WebID+TLS, I'm sure the larger W3C community would be thrilled to work out solutions for your use-cases based on FIDO - and maybe   OAuth (also not perfect, but possible to be improved to give better privacy/anonymity [3])  -  that use the JOSE specs for key material. This would make the exciting coding projects being done by yourself and others compatible with Web while providing better privacy and security properties that the X.509/TLS stack.

So, perhaps a reasonable compromise is that we can not immediately disable <keygen> until FIDO is implemented in browsers, and then remove it, while warning developers *now.*

 

    yours,

          harry


 

 

 

On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:



   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.


Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.




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


Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.


   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)


If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until




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


A solution would be then to extend the standrad in future versions and code compatibly to that.




   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.


Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time

If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?





   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.


There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.

If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly



   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.


Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.




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


The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.







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


I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.



   While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 


What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,






   and represents an authentication scheme that does not work well for the web. 


Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?





   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.


Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.

In the mean time, please fix bugs in client certs which are just a pain.

- Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
- Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.

- In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)

So don't abandon <keygen>, fix it.

And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  

In the meantime please support keygen and improve client cert handling. 

timbl









   [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

 

 

 

123