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

[David Keeler]

[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

[Anne van Kesteren]

On Thu, Jul 30, 2015 at 1:35 AM, David Keeler <dke...@mozilla.com> wrote:
> 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.

Deprecating and adding counters seems meaningful. It's not supported
across all browsers and it seems unlikely to ever be successful. If we
can make that clear to more folks by console warnings and some
outreach that seems like a good thing to do for the web.

Safari still supporting it is somewhat worrisome. We're in the process
of implementing and standardizing many -webkit- features due to
Safari's dominance on mobile.


--
https://annevankesteren.nl/

[Teoli]

Do you think it is already worth to flag it as deprecated in the MDN
documentation as Google plans to remove it too?

Or should we wait until we add a message in the console when met (I
guess that is what will happen). [In that case don't forget the
dev-doc-need on that bug ;-) ]

--
Jean-Yves

[Anne van Kesteren]

On Thu, Jul 30, 2015 at 12:28 PM, Teoli
<news.fak...@localhost.invalid> wrote:
> Do you think it is already worth to flag it as deprecated in the MDN
> documentation as Google plans to remove it too?

Yeah, seems worth a note at least given that Microsoft doesn't ship it
either (nor plans to ever). I'll probably get the HTML Standard
updated too in due course.


--
https://annevankesteren.nl/

[Hubert Kario]

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

[Richard Barnes]

On Thu, Jul 30, 2015 at 6:33 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

> On Thu, Jul 30, 2015 at 12:28 PM, Teoli
> <news.fak...@localhost.invalid> wrote:

> > Do you think it is already worth to flag it as deprecated in the MDN
> > documentation as Google plans to remove it too?
>

> Yeah, seems worth a note at least given that Microsoft doesn't ship it
> either (nor plans to ever). I'll probably get the HTML Standard
> updated too in due course.
>

+1



>
>
> --
> https://annevankesteren.nl/
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Richard Barnes]

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

[Hubert Kario]

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]

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

[helpcrypto helpcrypto]

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]

MS ships an equivalent JS api
https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx

Were there discussions on ways to improve keygen? It seems like what happened is that the JS crypto API led people to believe that an equivalent would be found there, and this equivalent never appeared.

>
>
> --
> https://annevankesteren.nl/

[henry...@gmail.com]

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.

[henry...@gmail.com]

On Thursday, 30 July 2015 01:35:52 UTC+2, 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/kmHsyMGJZAMJ
>

One of the elements of his detailed analysis is under fire, namely that the reliance of keygen on PEM is a key security hole. I made this case in more detail here:
https://github.com/whatwg/html/issues/102

But to avoid your needing to click on the link here it is in full:

<keygen> has been deprecated a few days ago, and the issue has been taken up by @timbl on the Technical Architecture Group as it removes a useful tool in the asymmetric public key cryptography available in browsers.

One reason given for deprecating that recurs often is that keygen uses MD5 which opens an attack vector presented in a very good paper "MD5 considered harmful today" at the Chaos Communication Congress in Berlin in 2008 by a number of researchers of which Jacob Appelbaum ( aka. @ioerror ) . ( That was the time when Julian Assange was working freely on Wikileaks, so you can even hear him ask a question at the end )

The slides are here:
https://www.trailofbits.com/resources/creating_a_rogue_ca_cert_slides.pdf
The video is here:
http://chaosradio.ccc.de/25c3_m4v_3023.html

In short they were able to create a fake Certificate Authority (CA) because the CA signed its certificates with MD5 and they were able to create hash collisions, to use the certificate signed by the CA
and change some information in it to produce their own top level certificate, with which
they could create a certificate for any site they wished to! ( Pretty awesomely bad - though they did this carefully to avoid misuse ). This is why projects such as IETFs DANE, DNSSEC, and many other improvements to the internet infrastructure are vital.

This was 7 years ago, so all of this should be fixed by now. There should be no CA signing
Server Certificates with MD5 anymore.

Great. But that has nothing to do with what is going on with <keygen>. The problem
may well be that the documentation of <keygen> is misleading here. The WHATWG documentation on keygen currently states:

If the keytype attribute is in the RSA state: Generate an RSA key pair using the settings given by the user, if appropriate, using the md5WithRSAEncryption RSA signature algorithm (the signature algorithm with MD5 and the RSA encryption algorithm) referenced in section 2.2.1 ("RSA Signature Algorithm") of RFC 3279, and defined in RFC 3447. [RFC3279] [RFC3447]
By whether or not keygen wraps the key and signs it with MD5 is of not much importance, since this is the keyrequest we are speaking of here, not the generated certificate!

To summarise how the keygen is actually used:
1. The browser creates a public/private key, saves the private key in the secure keychain
2. and sends the public key in an spkac request to the server which
3. which on receipt of the certificate request and verification of the data, uses that to create a Client Certificate using any signature algorithm it wants for the creation of the certificate ( And so it SHOULD NOT USE MD5: see CCC talk above )
4. which it returns using one of the x509 mime types available to it,

Here is an illustration of the flow that we use in the WebID-TLS spec to illustrate this:
Certificate Creation Flow

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

To see some real code implementing this I point you to my ClientCertificateApp.scala code that receives a certificate Request, and either returns an error or a certificate.
The key parts of the code are extracted below
https://github.com/read-write-web/rww-play/blob/f587382935c85e9f8916d5065434f7525c328ab9/app/controllers/ClientCertificateApp.scala

def generate = Action { implicit request =>
certForm.bindFromRequest.fold(
errors => BadRequest(html.webid.cert.genericCertCreator(errors)),
certreq => {
Result(
//https://developer.mozilla.org/en-US/docs/NSS_Certificate_Download_Specification
header = ResponseHeader(200, Map("Content-Type" -> "application/x-x509-user-cert")),
body = Enumerator(certreq.certificate.getEncoded)
)
}
)
}

CertForm just takes the data from the html form (verifies all fields are ok) and generates a CertReq object. ( or it can also take a CertReq object and generate a form, so that errors can be shown to the user )

val certForm = Form(
mapping(
"CN" -> email,
"webids" -> list(of[Option[URI]]).
transform[List[URI]](_.flatten,_.map(e=>Some(e))).
verifying("require at least one WebID", _.size > 0),
"spkac" -> of(spkacFormatter),
"years" -> number(min=1,max=20)
)((CN, webids, pubkey,years) => CertReq(CN,webids,pubkey,tenMinutesAgo,yearsFromNow(years)))
((req: CertReq) => Some(req.cn,req.webids,null,2))
)

The spkacFormatter just returns a public key. ( It plays around with testing the challenge, but I am not sure what that is for - would like to know ).

Anyway as I wrote above: if successful the generate method returns an encoded certificate with the right mime type. And as you can see we create a certificate with SHA1withRSA

val sigAlgId = new DefaultSignatureAlgorithmIdentifierFinder().find("SHA1withRSA")
val digAlgId = new DefaultDigestAlgorithmIdentifierFinder().find(sigAlgId)
val rsaParams = CertReq.issuerKey.getPrivate match {
case k: RSAPrivateCrtKey =>
new RSAPrivateCrtKeyParameters(
k.getModulus(), k.getPublicExponent(), k.getPrivateExponent(),
k.getPrimeP(), k.getPrimeQ(), k.getPrimeExponentP(), k.getPrimeExponentQ(),
k.getCrtCoefficient());
case k: RSAPrivateKey =>
new RSAKeyParameters(true, k.getModulus(), k.getPrivateExponent());
}


val sigGen = new BcRSAContentSignerBuilder(sigAlgId, digAlgId).build(rsaParams);
x509Builder.build(sigGen)
So the MD5 plays no serious role in all this.

This should not be a big surprise. The only thing of value sent to the server is the public key. It sends back a certificate based on that public key ( and other information it may have on the user ). But the only one to be able to use that certificate is the person owning the private key.

Now my code could presumably be improved in many places I doubt not. But this should show how
<keygen> is actually used. After all remember that <keygen> was added 10 years after it appeared in browsers, and that there was not that much discussion about the documentation when it was added.

I then posted a certificate I created using keygen and the server code described above. As you can see from the openssl command there is no MD5 in the resulting certificate.

$ openssl pkcs12 -clcerts -nokeys -in ~/Certificates.p12 | openssl x509 -noout -text
Enter Import Password:
MAC verified OK
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
01:4c:19:67:ea:05
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=WebID, O={}
Validity
Not Before: Mar 14 17:39:42 2015 GMT
Not After : Mar 13 17:49:42 2019 GMT
Subject: dnQualifier=he...@bblfish.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:da:b9:d1:e9:41:f6:f8:5a:08:63:16:9d:0d:b6:
32:8d:1d:4a:15:a7:1d:ff:e3:d4:f4:d0:87:52:a5:
2f:b1:45:4d:73:58:e4:a5:ec:f3:50:1e:39:24:bc:
02:52:f3:00:4b:0b:b2:1a:0d:6b:64:ca:05:3f:0f:
bc:b5:a5:4e:c9:3e:be:2d:c9:b9:1e:4c:43:2b:82:
78:84:c4:cc:2a:d8:a1:02:b4:6d:2a:20:17:bf:45:
d9:d4:c8:8a:56:4d:42:02:34:48:4a:1b:2e:44:6d:
bb:4c:d4:38:e7:9c:24:66:ce:31:0f:32:77:73:a7:
79:d2:4e:d7:b6:0a:05:a6:18:b9:84:75:7b:94:6d:
67:ba:79:f2:e0:64:e6:ae:d3:8b:d6:55:9c:e7:fc:
95:02:72:08:23:d5:6d:b1:c0:34:09:93:67:d7:db:
27:b6:bd:af:da:8c:c4:83:47:13:3f:4a:14:67:5f:
67:5f:b4:84:ce:32:df:66:c1:1a:36:38:fa:84:d5:
be:69:b1:a6:f2:38:11:5d:ef:9b:0f:79:bb:25:c0:
cb:7e:4a:39:45:9a:08:29:b1:fd:35:c0:d1:db:dd:
60:f9:c6:79:d8:94:15:ed:7e:a4:1e:b0:2f:bc:01:
6f:c0:e7:92:cb:96:98:c9:f4:db:84:2c:da:d5:b5:
f5:c9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name: critical
URI:http://bblfish.net/people/henry/card#me
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Key Agreement, Certificate Sign
X509v3 Basic Constraints: critical
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME
Signature Algorithm: sha1WithRSAEncryption
03:25:38:47:76:34:ba:da:0b:40:ea:75:63:98:6b:b0:0b:b6:
11:85:c7:b1:c4:91:cc:5c:99:a5:b5:01:24:6f:1f:8c:03:39:
80:03:e7:50:59:9f:b0:48:6e:e7:16:b8:b7:92:6f:31:cd:cc:
ba:60:40:08:9e:3c:38:5d:19:94:fd:2c:be:6d:84:57:d4:ea:
7f:54:a7:69:73:aa:37:a4:b8:81:21:0c:65:dc:f1:f6:a3:40:
d1:18:cf:04:a4:d6:8b:9a:1f:43:c2:67:4a:0e:8d:00:b7:e8:
49:e3:b7:d5:f9:00:0f:98:32:b2:09:5e:ca:c0:44:37:dc:df:
3b:57:e0:c2:5a:8a:79:0d:55:7a:4a:73:4a:24:64:27:e5:16:
78:d4:c9:35:5e:f8:67:9c:e9:41:bd:c6:25:6b:1b:d7:03:c1:
af:64:d0:e3:0a:ea:58:a4:bc:3a:a4:8f:51:8d:33:58:ed:ba:
af:3d:b7:75:28:32:33:76:65:80:56:ae:ec:43:db:9e:7e:4b:
74:f5:88:07:9f:2d:e8:74:f1:89:d1:af:52:34:07:52:f3:54:
2f:60:fd:de:96:f6:00:67:2e:8f:10:23:e6:af:95:bf:a6:3c:
61:0d:8c:24:47:cf:52:45:0f:96:ee:ca:3a:69:82:69:3b:20:
87:06:5c:58

Watch out that if you look at this certificate with viewers such as OSX keychain they will nevertheless show an MD5 signature - but that is not in the certificate itself. I checked with the openssl folks.

[Martin Thomson]

Henry, I would rather you attempt to address Ryan's point 5, namely:

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.

The key generation capability exists today with webcrypto. I'm
actually more interested in the consequences of the MIME-type handling
and it's interaction with key stores on the browser. That is the more
relevant piece of this whole issue. I know that it is at the core of
the argument.

I honestly think that the best thing here - given the current state -
is to treat this as an opportunity to ask for new work in the W3C. We
can examine these needs on their own merits and determine if investing
in new technology based on TLS client certificates is the right thing
for the web.

[henry...@gmail.com]

> On 4 Sep 2015, at 22:43, Martin Thomson <m...@mozilla.com> wrote:
> Henry, I would rather you attempt to address Ryan's point 5, namely:
>
> 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.
>
> The key generation capability exists today with webcrypto. I'm
> actually more interested in the consequences of the MIME-type handling
> and it's interaction with key stores on the browser. That is the more
> relevant piece of this whole issue. I know that it is at the core of
> the argument.

I asked for more details about this issue and it is not clear to me what the issue actually is here. A certificate served by a server with the application/x-x509-user-cert mime type as I do in my scala code [1] does not contain a private key.

def generate = Action { implicit request =3D>

certForm.bindFromRequest.fold(
errors => BadRequest(html.webid.cert.genericCertCreator(errors)),
certreq => {
Result(

// https://developer.mozilla.org/en-US/docs/NSS_Certificate_Download_Specification

header = ResponseHeader(200, Map("Content-Type" -> "application/x-x509-user-cert")),
body = Enumerator(certreq.certificate.getEncoded)
)
}
)
}

As I understand, it will only on reception be inserted by the browser to the keystore,
if the browser has generated the private key, which it would have kept
in its keystore during public/private key creation. [2] In any case a client =
certificate without a private key would not be useable for authentication, signature, etc...

The WebCrypto APIs at present do not have access to the keystore , so they can only store the data in Local Web Storage, which has the problems of making the keys =
visible to all same origin JS and can also only be used by the same origin =
defeating the purpose of asymmetric public key crypt as a way to authenticate across sites. ( mention has been made of potential avenues, but these are still on the =
drawing board ).

So can you detail the problem? The certificate that is added to the browser should only be allowed to be used when the user of the browser gives his assent. So there is no privacy leakage.

> I honestly think that the best thing here - given the current state -
> is to treat this as an opportunity to ask for new work in the W3C. We
> can examine these needs on their own merits and determine if investing
> in new technology based on TLS client certificates is the right thing
> for the web.

That is exactly what Tim Berners Lee is asking for in his recent message to the TAG
https://lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html

* Don't deprecate keygen until we are all certain that new technology
actually does replace the functionality that keygen usefully allows (
which is not necessarily the way it is most widely used ! )
* find out if keygen actually has something to offer that the other
techs cannot. If so
* Fix issues with keygen and client certificates where they exist and research possible improvements there
* Consider improvements at the TLS and HTTP layer that would make this better
* Work in the open on clearly defined issues, make implicit assumptions explicit and see if they hold up.

There are a lot of people from different areas involved in this discussion and it is clear nobody can have a full overview of the subject. Most people here I bet have little knowledge of what can be done with the semantic web ( but I am sure there are many predudices about it ). Others are less knowledgeable about UI design, others know a
lot less about cryptography, etc.. etc... There is movement in the HTTP2.0 group and in TLS3.0 which would make it possible to perhaps do much more coherent things with client certificates - and perhaps we don't need to be stuck with X509! And there is all the new stuff coming from JS Web Workers and the FIDO alliance ( some of which may be good, but also perhaps some of which may not be so good )

Henry

[1]
https://github.com/read-write-web/rww-play/blob/f587382935c85e9f8916d50654=
34f7525c328ab9/app/controllers/ClientCertificateApp.scala
[2] for details see the sequence diagram we wrote up on the WebID-TLS spec, and which would clearly be helpful if it appeared in the html5 spec
http://www.w3.org/2005/Incubator/webid/spec/tls/#certificate-creation

Social Web Architect
http://bblfish.net/

[Henry Story]

> On 4 Sep 2015, at 22:43, Martin Thomson <m...@mozilla.com> wrote:
>
> Henry, I would rather you attempt to address Ryan's point 5, namely:
>
> 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.
>
> The key generation capability exists today with webcrypto. I'm
> actually more interested in the consequences of the MIME-type handling
> and it's interaction with key stores on the browser. That is the more
> relevant piece of this whole issue. I know that it is at the core of
> the argument.

I asked for more details about this issue and it is not clear to me what
the issue actually is here. A certificate served by a server with the
application/x-x509-user-cert mime type as I do in my scala code [1]
does not contain a private key.

def generate = Action { implicit request =>
certForm.bindFromRequest.fold(
errors => BadRequest(html.webid.cert.genericCertCreator(errors)),
certreq => {
Result(
//https://developer.mozilla.org/en-US/docs/NSS_Certificate_Download_Specification
header = ResponseHeader(200, Map("Content-Type" -> "application/x-x509-user-cert")),
body = Enumerator(certreq.certificate.getEncoded)
)
}
)
}

As I understand, it will only on reception be inserted by the browser to the keystore,
if the browser has generated the private key, which it would have kept in its

keystore during public/private key creation. [2] In any case a client certificate without

a private key would not be useable for authentication, signature, etc...

The WebCrypto APIs at present do not have access to the keystore , so they can only store

the data in Local Web Storage, which has the problems of making the keys visible to
all same origin JS and can also only be used by the same origin defeating the purpose of
asymmetric public key crypt as a way to authenticate across sites. ( mention has been made of potential avenues, but these are still on the drawing board ).

So can you detail the problem? The certificate that is added to the browser should only be allowed to be used when the user of the browser gives his assent. So there is no privacy leakage.

>
> I honestly think that the best thing here - given the current state -
> is to treat this as an opportunity to ask for new work in the W3C. We
> can examine these needs on their own merits and determine if investing
> in new technology based on TLS client certificates is the right thing
> for the web.

I think that is exactly what Tim Berners Lee is asking for in his recent message to the TAG

https://lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html

* Don't deprecate keygen until we are all certain that new technology actually does replace the functionality that keygen usefully allows ( which is not necessarily the way it is most widely used ! )
* find out if keygen actually has something to offer that the other techs cannot. If so
* Fix issues with keygen and client certificates where they exist and research possible improvements there
* Consider improvements at the TLS and HTTP layer that would make this better
* Work in the open on clearly defined issues, make implicit assumptions explicit and see if they hold up.

There are a lot of people from different areas involved in this discussion and it is clear nobody can have a full overview of the subject. Most people here I bet have little knowledge of what can be done with the semantic web ( but I am sure there are many predudices about it ). Others are less knowledgeable about UI design, others know a lot less about cryptography, etc.. etc... There is movement in the HTTP2.0 group and in TLS3.0 which would make it possible to perhaps do much more coherent things with client certificates - and perhaps we don't need to be stuck with X509! And there is all the new stuff coming from JS Web Workers and the FIDO alliance ( some of which may be good, but also perhaps some of which may not be so good )

Henry

[1] https://github.com/read-write-web/rww-play/blob/f587382935c85e9f8916d5065434f7525c328ab9/app/controllers/ClientCertificateApp.scala

[Martin Thomson]

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
>

[Martin Thomson]

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.

On Fri, Sep 11, 2015 at 9:42 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> [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).