Google dominate the space because they have an active, robust trust-store program that they manage well. Apple the same. Mozilla and Microsoft too (though to a lesser extent).

If any ecosystem - such as XMPP - wishes to, they could start their own root-program, but many simply copy what Chrome or Mozilla do and then are surprised when things change.

A public CA checks it one-time, when it's being issued. Most/all mTLS use-cases don't do any checking of the client cert in any capacity. Worse still, some APIs (mainly for finance companies) require things like OV and EV, but of course they couldn't check the Subject DN if they wanted to.

If it's for auth, issue it yourself and don't rely on a third-party like a public CA.

A federated ecosystem of servers that need to verify each other based on their domain name as the identity is the prime use-case for a public CA to issue domain-verified client certificates. XMPP happens to be this ecosystem.

Rolling out a private PKI for XMPP, with a dedicated Root CA, would be a significant effort, essentially redoing all the hard work of LetsEncrypt, but without the major funding, thus ending up with an insecure solution.

We make use of the public CAs, that have been issuing TLS certificates based on domain validation, for quite a few years now, before the public TLS CAs have been subverted to become public HTTPS-only CAs by Google and the CA/Browser Forum.

> Rolling out a private PKI for XMPP, with a dedicated Root CA, would be a significant effort

Rolling out a change that removes the EKU check would not be that much effort however.

That's exactly what prosody is doing, but it's a weird solution. Essentially, they're just ignoring the missing EKU flag and pretend it would be there, violating the spec.

It seems weird to first remove the flag and then tell everyone to update their servers to ignore the removal. Then why remove it in the first place?

I think you're confusing different actors here. The change was made by the CA/B Forum, the recommendation is just how it is if you want to use a certificate not for the purposes intended.

But it does mean that the CA/B requirement change has zero positive effect on security of anything and only causes pointless work and breakage.

Or to put it another way, the pragmatic response of the XMPP community shows that the effect of the change is not to remove the clientAuth capability from any certs but to effectively add it to all serverAuth certs no matter what the certificate says.

Yes, this is what is happening. It isn't happening fast enough, so some implementations (especially servers that don't upgrade often enough, or running long-term-support OS flavors) will still be affected. This is the impact that the original article is warning about.

My point was that this is yet another change that makes TLS operations harder for non-Web use cases, with the "benefit" to the WebPKI being the removal of a hypothetical complexity, motivated by examples that indeed should have used a private PKI in the first place.

> A public CA checks it one-time, when it's being issued.

That's the same problem we have with server certs, and the general solution seems to be "shorter cert lifetimes".

> Worse still, some APIs (mainly for finance companies) require things like OV and EV, but of course they couldn't check the Subject DN if they wanted to.

Not an expert there, but isn't the point of EV that the CA verified the "real life entity" that requested the cert? So then it depends on what kind of access model the finance company was specifying for its API. "I don't care who is using my API as long as they are a company" is indeed a very stupid access model, but then I think the problem is deeper than just cert validation.

> "I don't care who is using my API as long as they are a company" is indeed a very stupid access model, but then I think the problem is deeper than just cert validation

It's not stupid if you reframe it as "you can only use my API if you give me a cryptographically verifiable trace to your legal identity".

That's true if it worked, but I think there was the problem that EV names aren't always enough to trace back the legal entity? At least that's what I read, it might be wrong.

> That's the same problem we have with server certs, and the general solution seems to be "shorter cert lifetimes".

No it isn't, and that's not the reason why cert lifetimes are getting smaller.

Cert lifetimes being smaller is to combat certs being stolen, not man in the middle attacks.

Not really, no. There are a number of reasons for cert lifetimes being made shorter.

Publicly-trusted client authentication does nothing. It's not a thing that should exist, or is needed.

It does if the "client" in the TLS sense is really a public server in a federated network. Like for example in XMPP which you may have heard of.

Then you specify your protocol to accept server certs from clients

I don't think this is true. It's something that could be useful, with some sort of ACME-like automated issuance, but should definitely be issued from a non-WebPKI certificate authority.

Client authentication with publicly-trusted (i.e. chaining to roots in one of the major 4 or 5 trust-store programs) is bad. It doesn't actually authenticate anything at all, and never has.

No-one that uses it is authenticating anything more than the other party has an internet connection and the ability, perhaps, to read. No part of the Subject DN or SAN is checked. It's just that it's 'easy' to rely on an existing trust-store rather than implement something secure using private PKI.

Some providers who 'require' public TLS certs for mTLS even specify specific products and CAs (OV, EV from specific CAs) not realising that both the CAs and the roots are going to rotate more frequently in future.

    No part of the Subject DN or SAN is checked.

Is this true of XMPP? I thought it enforced that the SAN matched the XMPP identifier in question

A client cert can be stored, so it provides at least a little bit of identification certainty. It's very hard to steal or impersonate a specific client cert, so the site has a high likelihood of knowing you're the same person you were when you connected before (even though the initial connection may very well not have ID'd the correct person!). That has value.

But it also doesn't involve any particular trust in the CA either. Lets Encrypt has nothing to offer here so there's no reason for them to try to make promises.

Eh, it's pretty easy to impersonate if the values in the certificate aren't checked, and you could get one from any of a list of public CAs.

If you're relying on a certificate for authentication - issue it yourself.

Point being that if you get a valid TLS connection from a client cert, and then you get another valid connection from the same cert tomorrow, you can be very certain that the entity connecting is either the same software environment that connected earlier, or an attacker that has compromised it. You can be cryptographically certain that it is not an attacker that hasn't effected a full compromise of your client.

And there's value there, if you're a server. It's why XMPP wants federated servers to authenticate themselves with certificates in the first place.

If that's all you want to accomplish, you don't need WebPKI. Just generate a private key and a self-signed certificate.

(This is basically how Let's Encrypt / ACME accounts work)

How do I convince the tens of thousands of other servers that my private key can be trusted without some kind of third party trust architecture?

There's DANE but outside of maybe two countries that's impractical to set up because DNS providers keep messing up DNSSEC.

I can't believe this was downvoted. Seriously a Certificate is binding a public key and the attributes (mainly the identity). If you don't need to use the attributes, you don't need a certificate!

> This is basically how Let's Encrypt / ACME accounts work

That's how they're implemented. How they "work" is a trivial pushbutton thing as documented by a well-known and trusted provider who cares deeply about simple user experience.

"Just self-sign a cert" is very much not the story XMPP wants their federated server operators to deal with.

You are correct, and the answer is - no-one using publicly-trusted TLS certs for client authentication is actually doing any authentication. At best, they're verifying the other party has an internet connection and perhaps the ability to read.

It was only ever used because other options are harder to implement.

It seems reasonable for server-to-server auth though? Suppose my server xmpp.foo.com already trusts the other server xmpp.bar.com. Now I get some random incoming connection. How would I verify that this connection indeed originates from xmpp.bar.com? LE-assigned client certs sound like a good solution to that problem.

> It seems reasonable for server-to-server auth though? Suppose my server xmpp.foo.com already trusts the other server xmpp.bar.com.

If you already trust xmpp.foo.com, then you probably shouldn't be using PKI, as PKI is a complex system to solve the problem where you don't have preexisting trust. (I suppose maybe PKI could be used to help with rolling over certs)

No, the problem it was solving was "how do I verify that an incoming connection is actually from xmpp.foo.com and not from an impostor?"

You could also solve this with API keys or plain old authentication, but all of those require effort on xmpp.foo.com's side to specifically support your server.

Client certs seem better suited in that regard. A server can generate a trusted client cert once, and then everyone else can verify connections from that server without having to do any prior arrangements with it.

Which is almost exactly why WebPKI doesn't want to support such use-cases. Just this EKU change alone demonstrates how it can hinder WebPKI changes.

Can you point out, at which point in time exactly, the public TLS PKI infrastructure has been reduced to WebPKI?

Can you point out at which point in time exactly it was designed to serve every use-case?

The public TLS PKI was never supposed to serve every use case and you know it. But let me point out when it was possible to get a public CA certificate for an XMPP server with SRVname and xmppAddr:

  Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1096750 (0x10bc2e)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
        Validity
            Not Before: May 27 16:16:59 2015 GMT
            Not After : May 28 12:34:54 2016 GMT
        Subject: C = DE, CN = chat.yax.im, emailAddress = hostmaster@yax.im
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
                DNS:chat.yax.im, DNS:yax.im, xmppAddr:chat.yax.im, dnsSRV:chat.yax.im, xmppAddr:yax.im, dnsSRV:yax.im

Ironically, this was the last server certificate I obtained pre-LetsEncrypt.

So you understand that there are different purposes as well. Are you saying that you can't get a client auth certificate any more?

Huh? The entire purpose of that EKU change was to disallow that usecase. How did that demonstrate problems for WebPKI?

This post here is the demonstration, that some non-WebPKI purpose is causing issues and complaints. This has happened before with SHA-1 deprecation. WebPKI does not want this burden and should not have this burden.

Ok, so this is an official split of "WebPKI" and "everything else PKI" then?

Last time I checked, Let's Encrypt was saying they provide free TLS certs, not free WebPKI certs. When did that change?

You are being pedantic but also pedantically incorrect.

Lets encrypt provides value by providing signed TLS certs that are enrolled in webPKI (i.e. trusted by browsers).

If they were just provided a (not necessarily trusted) tls cert, like what anyone can generate from the command line, nobody would use them.

Let's Encrypt also provides value by providing signed TLS certificates that are enrolled in all major operating systems, and that can be used to authenticate any TLS server.

This is a significant and important use case that's totally ignored by the "WebPKI" proponents, and there is no alternative infrastructure that would provide that value if WebPKI would e.g. decide to add certificate constraints limiting issued certificates to TCP/433.

That's being overly pedantic. PKIs for different purposes have been separate for a while, if not from the start. LE is still giving you a "TLS cert".

Great circular reasoning there buddy.

It’ll be 5 years soon.

...which is arguably the problem. Firefox. Thunderbird. That should be it. According to their own site, beyond that they have the browser app for mobile devices. A VPN service, an email-forwarding service, and MDN. Hardly 'many products'.

One could argue that the only product that really matters is the ability to have a default search engine. I checked out their Wikipedia[0] article and their financials table has a column dedicated to the percent of revenue derived from Google—81-95%, depending on the year.

It feels a little like when Microsoft invested in Apple back in the 90s. Microsoft needed Apple so they didn’t look like too much of a monopoly. Google has been funding Mozilla’s whole existence for at least 20 years. At first it may have purely been do dominate search, but at some point I think the incentives shifted to Google needing Firefox so they can claim they aren’t a monopoly in the browser space and competition exists.

[0] https://en.wikipedia.org/wiki/Mozilla_Corporation

You've clearly never built a product. One product alone requires a CEO. More than one, much more so.

And anyway you're factually wrong. They produce much more than what you listed, many of their undertakings are contributions to open-source, the development of web standards, underlying technologies that browsers (not just Firefox) use to render the web, etc.

You're being childish and somewhat absurdly so. Mozilla and Firefox are a large part of the reason the modern web is usable (in the technical sense - usability for the deaf and blind, screen readers, etc)

I was mostly just typing out what they had listed under 'products' on their pages. I'm aware of what Mozilla do, know folks there and that have been there. They've been roundly criticised for adding 'products' of questionable value to their core userbase, rightly so in my opinion.

Yes, many of the projects have been failures -- just like at countless other companies -- but that doesn't change the fact that an organization needs a leader. Your original comment is still nonsensical.

Not quite true - some CAs were not 'held hostage' - some agree with the changes and supported them. See the endorsers for SC-081.

Can I ask - if you're using publicly-trusted TLS server certificates for client authentication...what are you actually authenticating? Just that someone has a certificate that can be chained back to a trust-anchor in a common trust-store? (ie your authentication is that they have an internet connection and perhaps the ability to read).

Where did you get 17 days from?

There was talking going on in one of the CA/Browser Forum regarding certificate expirations, and how they looked at potentially 17 days. The 45 days was a compromise, but the whole 17 days was never removed from the table, and was still considered as a future option.

Honestly don't recall discussing 17 days, but I could be wrong. 47 days was a 'compromise' in that it's a step-down over a few years rather than a single big-bang event dropping from 397->90/47/less.