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

On 1 September 2015 at 16:08, Tim Berners-Lee <timbl@w3.org> 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:
>
> 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
>
>
>
> 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
>
>
>