On Thursday, 30 July 2015 20:32:07 UTC+2, Richard Barnes wrote: > On Thu, Jul 30, 2015 at 6:53 AM, Hubert Kario <hka...@redhat.com> wrote: > > > On Wednesday 29 July 2015 16:35:41 David Keeler wrote: > > > [cc'd to dev-security for visibility. This discussion is intended to > > > happen on dev-platform; please reply to that list.] > > > > > > Ryan Sleevi recently announced the pre-intention to deprecate and > > > eventually remove support for the <keygen> element and special-case > > > handling of the application/x-x509-*-cert MIME types from the blink > > > platform (i.e. Chrome). > > > > > > Rather than reiterate his detailed analysis, I'll refer to the post here: > > > > > > > > https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMG > > > JZAMJ > > > > <snarky sarcasm> > > Well, gmail doesn't support S/MIME or GPG/MIME so obviously <keygen> is > > useless and should be removed. > > </snarky sarcasm> > > > > > Much, if not all, of that reasoning applies to gecko as well. > > > Furthermore, it would be a considerable architectural improvement if > > > gecko were to remove these features (particularly with respect to e10s). > > > Additionally, if they were removed from blink, the compatibility impact > > > of removing them from gecko would be lessened. > > > > > > I therefore propose we follow suit and begin the process of deprecating > > > and removing these features. The intention of this post is to begin a > > > discussion to determine the feasibility of doing so. > > > > because pushing people to use Internet Explorer^W^W Spartan^W Edge in > > enterprise networks is a good plan to continue loosing market share for > > Mozilla products! /s > > > > lack of easy, cross-application certificate deployment is the _reason_ for > > low > > rates of deployment of client certificates, but where they are deployed, > > they > > are _critical_ > > > > <keygen> doesn't help you with cross-application deployment. After all, IE > doesn't support it. > > > > > you really suggest I should tell regular people to copy paste CSR's, keep > > safe > > their private keys and be able to pair keys to certs when even programmers > > and > > system administrators have problems with current certificate deployments? > > (user certs vs web server certs) > > > > The point has been made a couple of times that you can pretty effectively > polyfill <keygen> with either WebCrypto or JS crypto libraries. You can do > the whole key generation and enrollment process that way, and the only > manual step is to download the cert and import it into the browser. Do it > with JS, and you can support far more browsers than <keygen> supports today.
I don't think you can. I argued this in more detail on the html5 commit to deprecate keygen https://github.com/whatwg/html/commit/1b438067d84da2ee95988842cdd8fe2655444936 which I noted has not had much discussion other than a PR that was quickly accepted. I opened an issue on the whatwg github database so that the discussions could be cross referenced, and the arguments be out in the open. > > --Richard > > > > suggesting removal of such a feature because is not often used is like > > suggesting removal of mains valve because it is not used often > > > > And I say it as a former sysadmin, not Red Hat employee. > > -- > > Regards, > > Hubert Kario > > > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
