Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

On the future of <keygen> and application/x-x509-*-cert MIME handling

214 views
Skip to first unread message

David Keeler

unread,
Jul 29, 2015, 7:35:49 PM7/29/15
to dev-platform, dev-se...@lists.mozilla.org
[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/kmHsyMGJZAMJ

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.

Cheers,
David

signature.asc

Hubert Kario

unread,
Jul 30, 2015, 6:54:33 AM7/30/15
to dev-se...@lists.mozilla.org, dev-platform, David Keeler
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_

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)

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

signature.asc

Ian G

unread,
Jul 30, 2015, 7:58:31 AM7/30/15
to dev-se...@lists.mozilla.org


On 30/07/2015 11:53, Hubert Kario wrote:
> 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_


If there is one thing that definitively improves security for users it
is client certs. If there is one thing that screws client certs for
everyone, it's non-investment by vendors. If there's one thing that the
vendors couldn't figure out how to monetise and franchise, it's client
certs.

Connect the dots...



iang

Richard Barnes

unread,
Jul 30, 2015, 2:32:09 PM7/30/15
to Hubert Kario, David Keeler, dev-se...@lists.mozilla.org, dev-platform
> 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.

--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-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>

Ryan Sleevi

unread,
Jul 30, 2015, 2:40:20 PM7/30/15
to mozilla.de...@googlegroups.com, dev-platform, dev-se...@lists.mozilla.org, David Keeler, Hubert Kario
On Thu, Jul 30, 2015 at 11:32 AM, Richard Barnes <rba...@mozilla.com>
wrote:

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

The exception being that Firefox allows arbitrary websites to provision for
smart card (by prompting the user to select the smart card). The
replacement for such functionality is not WebCrypto/JS, but would
presumably be accomplishable via an extension.

The existing approach already has issues for Firefox's e10s support, and
presumably Mozilla would have to do something similar to what Chrome/Blink
did (marshalling such messages over from the renderer to the browser), so
the <keygen> support would more or less have to be reimplemented for e10s
if it's still supported.

Hubert Kario

unread,
Jul 31, 2015, 7:01:07 AM7/31/15
to dev-se...@lists.mozilla.org, dev-platform, David Keeler, Richard Barnes
On Thursday 30 July 2015 14:32:01 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).
> > >
> > > 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.

and how removing <keygen> makes the situation better?

yes, Firefox doesn't deploy to system cert store (by default), but it's a bug
in Firefox, not a feature
--
Regards,
Hubert Kario
signature.asc

Hubert Kario

unread,
Jul 31, 2015, 7:17:40 AM7/31/15
to dev-se...@lists.mozilla.org, Ian G
On Thursday 30 July 2015 12:57:57 Ian G wrote:
> On 30/07/2015 11:53, Hubert Kario wrote:
> > 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_
>
> If there is one thing that definitively improves security for users it
> is client certs. If there is one thing that screws client certs for
> everyone, it's non-investment by vendors. If there's one thing that the
> vendors couldn't figure out how to monetise and franchise, it's client
> certs.
>
> Connect the dots...

and that's why we're working on stuff like
http://p11-glue.freedesktop.org/
and
https://fedoraproject.org/wiki/Changes/CryptoPolicy
to make use of proper crypto manageable, but this takes time
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc

helpcrypto helpcrypto

unread,
Aug 20, 2015, 8:39:42 AM8/20/15
to Hubert Kario, David Keeler, dev-se...@lists.mozilla.org, dev-platform, Richard Barnes
Hi

In our case, we use <keygen> to generate a keypair on our SSCD (smartcard)
using Firefox, cause -with the PKCS#11 module configured-, it asks where to
store the keys, so the user select CARD.

Using Webcrypto or other JS stuff I wont be able to populate my smartcards,
so -IMHO- you should keep it as long as there's a real alternative for this
kind of operations.
You already removed signText and since then I cannot use "national
certificates renewal" feature on Firefox (only on IE)...not with Edge or
Firefox.

I know a lot of colleagues with the same problem, and that's why there has
been a rumble about "out of scope smartcards on Webcrypto".

I could agree with you that smartcards are not intended for Web, they suck
and whatever...but if you start to remove this feature, then it's time I
start looking for other Job :P




On Fri, Jul 31, 2015 at 1:00 PM, Hubert Kario <hka...@redhat.com> wrote:

> On Thursday 30 July 2015 14:32:01 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).
> > > >
> > > > 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.
>
> and how removing <keygen> makes the situation better?
>
> yes, Firefox doesn't deploy to system cert store (by default), but it's a
> bug
> in Firefox, not a feature
> --
> Regards,
> Hubert Kario

helpcrypto helpcrypto

unread,
Aug 28, 2015, 4:35:03 AM8/28/15
to Hubert Kario, David Keeler, dev-se...@lists.mozilla.org, dev-platform, Richard Barnes
So...may I know if a decision was made?

<keygen> element is marked as deprecated on MDN, and as stated by rsleevi,
Chrome seems will drop it.

Will Mozilla do the same? Do you have a roadmap/date for such change? It's
going to be supported "by now" until next call?
Please, consider we are *that little percent *using the component "on a
weekly basis", so we have to start taking measures and planning changes, if
this is going to happen.

Thanks in advance.

henry...@gmail.com

unread,
Sep 5, 2015, 1:17:55 PM9/5/15
to mozilla-de...@lists.mozilla.org
There is a lot of debate about this on various lists including an Agenda item Tim Berners Lee brought up on the subject at the TAG "<keygen> being destroyed when we need it"
https://lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html

There were a lot of arguments on the blink forum but one key attack of keygen is that it is insecure because it uses MD5. I responded to that there, and put up a detailed explanation as to why that was not the case on the whatwg forum showing how the MD5 in the generated spkac is not important in the creation of the certificate, so the amazing attacks on certificate authorities demonstrated by Jacob Appelbaum and friends at the Chaos Communication Congress of 2008 do not apply here

https://github.com/whatwg/html/issues/102

Finally all browsers even IE have something like keygen. IE just used JS tied to ActiveX for it, which sadly forces one to use both at present if one wants to work with IE.

https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx

It would of course help if instead of having to split the conversation across N forums one could get together and work out these points one by one in the open. This is a complex topic, and it is all too easy to throw the baby out with the bath water here.

Martin Thomson

unread,
Sep 12, 2015, 12:30:12 AM9/12/15
to David Keeler, dev-se...@lists.mozilla.org, dev-platform
I have some questions, to which I was unable to find answers for in
the (numerous and long) threads on this subject.

1. When we download and install a client cert, what checking do we do?
Do we insist upon it meeting the same algorithm requirements we have
for servers with respect to use of things like short RSA keys and weak
hashes (MD5/SHA-1)?

2. What is the potential scope of use for a client certificate?
Global? The origin that provided it? Something in-between like
domain or domain plus subdomains?

I'll go and dig around in the code if I have to, but if someone has
the answers readily available, or wants to do the rummaging for me,
that would be much appreciated.

On Wed, Jul 29, 2015 at 4:35 PM, David Keeler <dke...@mozilla.com> 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/kmHsyMGJZAMJ
>
> 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.
>
> Cheers,
> David
>
>
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>

Ryan Sleevi

unread,
Sep 12, 2015, 12:42:41 AM9/12/15
to mozilla.de...@googlegroups.com, dev-platform, dev-se...@lists.mozilla.org, David Keeler
[No idea if these will show up on the lists since I'm not subscribed]

On Fri, Sep 11, 2015 at 9:30 PM, Martin Thomson <m...@mozilla.com> wrote:

> I have some questions, to which I was unable to find answers for in
> the (numerous and long) threads on this subject.
>
> 1. When we download and install a client cert, what checking do we do?
> Do we insist upon it meeting the same algorithm requirements we have
> for servers with respect to use of things like short RSA keys and weak
> hashes (MD5/SHA-1)?
>

No. These are client certs (generally for internal systems), for which
there are no imposed policies on (CA/B Forum or otherwise).

The only checking re: algorithms are those which NSS itself has not
disabled globally (MD5, minimum keysizes, etc), but only if they present as
parse errors - not as signature validation errors.

If it comes in as application/x-x509-user-cert (vs, say,
application/x-x509-ca-cert, which can be used to quickly add a root
certificate),
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsNSSCertificateDB.cpp#849
is what first parses/interprets the byte stream.

The validation requires:
1) That the user has an existing private key (from any source, <keygen> or
otherwise - so you can use this as an existence proof of whether or not a
user has a matching key). That's line 886
2) That it's syntactically valid for one of the forms Mozilla accepts - or
one of the ones it can munge into something it accepts (a liberal decoder)
- that's line 875

If so, it'll toast the user (via
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsNSSCertificateDB.cpp#810
) to let them know a certificate was installed (after the fact)

It'll then parse the rest of the bundle, and if they are certificates that
chain to a CA the user trusts, they'll also be imported (that's line 924)


This behaviour, however, is different than Chrome's in several ways
(primarily related to the parsing of the bundle and handling the additional
certificates). Chrome also explored a number of strict checks (is it a
valid client certificate from a known CA), but those had to be relaxed for
compatability with Firefox and the existing use cases.

We also explored not committing the generated key to the persistent
keystore until it'd been "confirmed" (via installation of a certificate),
except that broke nearly every <keygen> use case outside of WebID. In
particular, if you closed Chrome, we'd destroy the key - so that didn't
work for situations where you'd do a <keygen> enrollment, close Chrome, a
day later getting an email with a link from your CA w/ the certificate. So
you'd need some form of semi-persistent, origin-scoped storage if you went
that way.


>
> 2. What is the potential scope of use for a client certificate?
> Global? The origin that provided it? Something in-between like
> domain or domain plus subdomains?
>

Global - all domains, all applications. A common pattern, as seen on the
CA/Browser Forum list, is to use this method to configure S/MIME
certificates for Thunderbird, which uses the same NSS database.

Any other domain could do an existence test to see if a user has such a
certificate, by using <keygen> to create a key (which may or may not
involve prompting; various criteria there), using
application/x-x509-user-cert to deliver the user's cert that matches a
chosen ("attacker") issuer string, and then doing a TLS handshake that
requests a client certificate with the ca_names set to the attacker's
unique fingerprint.

The timing difference between the handshakes - whether or not the user has
a matching certificate and private key - can reveal to any domain who knows
the ca_names whether or not the user matches, at the cost of potentially
prompting the user (if they do match).

Martin Thomson

unread,
Sep 12, 2015, 12:56:01 AM9/12/15
to rsl...@chromium.org, David Keeler, dev-se...@lists.mozilla.org, dev-platform, mozilla.de...@googlegroups.com
Awesome, thanks Ryan.

This cements my opinion on their fate. These are not just old and
crufty, they are actively harmful. They can't be removed soon enough.

I'm not fundamentally opposed to the notion of having some sort of
site control of client authentication in general, and maybe even TLS
client authentication specifically, but this feature[7] cannot
continue to exist as part of the web platform.

[7] By which I mean the certificate download and install part, keygen
seems to be more on the cruft side based on what I've seen.

Richard Barnes

unread,
Nov 2, 2015, 8:54:53 PM11/2/15
to simonj...@googlemail.com, mozilla-de...@lists.mozilla.org
The short answer is "No, there is no comparably automated workflow for
setting HTTPS client certificates."

The slightly longer answer is: You can still automate issuing certificates
to clients in a way that the client's private key never leaves the host by
using something like WebCrypto and pki.js. Then you can have the user
download the cert and private key and install them.


On Wed, Oct 14, 2015 at 5:38 AM, <simonj...@googlemail.com> wrote:

> Hi,
>
> > This cements my opinion on their fate. These are not just old and
> > crufty, they are actively harmful. They can't be removed soon enough.
>
> Is there an alternate workflow that can replace it?
>
> The keygen tag is immensely useful to roll out client certificates to
> users:
>
> 1. have user call or visit, authenticate them
> 2. give them a one time password
> 3. direct them to a web page containing a <keygen> and a text field for
> the password
> 4. on submit, sign their key with the organization certificate, and return
> the cert
>
> I use this method basically in every small office installation I do -- it
> is more than sufficient security, because the applicant is usually directly
> known to the person maintaining the CA, and is really uncomplicated to use
> even for nontechnical users.
>
> The most difficult step at present is having the user copy the certificate
> from Firefox to Thunderbird, for IMAP and SMTP authentication (outgoing
> mail is SMTP+STARTTLS, with a rule that whitelisted client certificates get
> relay access).
>
> If that were to be dropped, what would I use to replace it?
>
> Simon
0 new messages