[nilslindemann]

> The current CA ecosystem is *heavily* driven by web browser vendors (i.e. Google, Apple, Microsoft and Mozilla), and they are increasingly hostile towards non-browser applications using certificates from CAs that they say only provide certificates for consumption by web browsers.

Let's translate and simplify:

> The current CA ecosystem is Google. They want that only Google-applications get certificates from CAs.

[direwolf20]

The correct translation is that everyone in WebPKI only wants the responsibility of running the Web PKI and not the Everything PKI.

[throw0101a]

> The correct translation is that everyone in WebPKI only wants the responsibility of running the Web PKI and not the Everything PKI.

The title of the current (2.2.2) CAB standard is "Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates":

* https://cabforum.org/working-groups/server/baseline-requirem...

§1.3, "PKI Participants", states:

> The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser and other relying‐party software applications.

IMHO "other relying-party software applications" can include XMPP servers (also perhaps SMTP, IMAP, FTPS, NNTP, etc).

If Google/Chrome doesn't want to allow it, good for them. But why do they get to dictate what others do?

[nilslindemann]

The correct translation is that Google only wants the Google PKI and not the Everything PKI.

[tialaramex]

For decades there have been a few entities interested in actually providing a working and trustworthy PKI for the Internet - it's called the Web PKI because in practice the only interested parties are always browser vendors.

There are always plenty of people who aren't interested in doing any hard work themselves but are along for the ride, and periodically some of those people are very angry because a system they expended no effort to maintain hasn't focused on their needs.

The Web PKI wasn't somehow blessed by God, people made this. If you do the hard work you can make your own PKI, with your own rules. If you aren't interested in doing that work, you get whatever the people who did the work wanted. This ought to be a familiar concept.

[morpheuskafka]

> Google-applications get certificates from CAs

Huh? Google does not even make a web server, or any kind of major servers, unless you count GCP load balancers or whatever. You are confusing their control of the client (which is still significantly shared with Apple and Microsoft since they control OS-level certificate trusts) with the server side, who are the "customers" of the CA. Google has almost no involvement in that and couldn't care less what kind of code is requesting and using certificates.

[forty]

Huh bis? Aren't people using Google browser mostly to use Google services hosted on Google servers? Haven't you heard of Google the search engine, Google maps, YouTube, Gmail, Google docs, etc?

[morpheuskafka]

But this is about SSL certificates. Google may account for say half of web traffic, but there are billions of other servers that account for the other half, and it has absolutely no care what web server or ACME client they are running or much else. It is concerned about the client experience and how it trusts certificates.

Google already has its own CA that is used for its own systems as well as to issue certificates for GCP customers. They don't interact with Lets Encrypt or any other external CA as far as I know for their own services.

[mmsc]

No. HTTPS certificates are being abused for non-https purposes. CAs want to sell certificates for everything under the sun, and want to force those in the ecosystem to support their business, even though https certificates are not designed to be used for other things (mail servers for example).

If CAs don't want hostility from browser companies for using https certificate for non-http/browser applications, they should build their own thing.

[MattJ100]

They weren't "HTTPS certificates" originally, just certificates. They may be "HTTPS certificates" today if you listen to some people. However there was never a line drawn where one day they weren't "HTTPS certificates" and the next day they were. The ecosystem was just gradually pushed in that direction because of the dominance of the browser vendors and the popularity of the web.

I put "HTTPS certificates" in quotes in this comment because it is not a technical term defined anywhere, just a concept that "these certificates should only be used for HTTPS". The core specifications talk about "TLS servers" and "TLS clients".

[growse]

The CAB is only concerned with the WebPKI. This means HTTPS.

There's loads of non web, non HTTPS TLS use cases, it's just the CAB doesn't care about those (why should it?).

[ge0rg]

This is technically true, and nobody contested the CABF's focus on HTTPS TLS.

However, eventually, the CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates. Nominally, the CAs are still offering "TLS certificates", but due to the pressure from the CABF, the allowed certificates are getting more and more limited, with the removal of SRVname a few years ago, and the removal of clientAuth that this thread is about.

I can understand the CABF position of "just make your own PKI" to a degree, but in practice that would require a LetsEncrypt level of effort for something that is already perfectly provided by LetsEncrypt, if it wouldn't be for the CABF lobbying.

[growse]

> CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates.

The restriction is on signing non web certificates with the same root/intermediate as is part of the WebPKI.

There's no rule (that I'm aware of?) that says the CAs can't have different signing roots for whatever use-case that are then trusted by people who need that use case.

[throw0101a]

> The CAB is only concerned with the WebPKI. This means HTTPS.

[citation needed]

The title of their current (2.2.2) standard is "Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates":

* https://cabforum.org/working-groups/server/baseline-requirem...

§1.3, "PKI Participants", states:

> The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser and other relying‐party software applications.

IMHO "other relying-party software applications" can include XMPP servers (also perhaps SMTP, IMAP, FTPS, NNTP, etc).

[growse]

> [citation needed]

My citation is the membership of the CAB.

> IMHO "other relying-party software applications" can include XMPP servers (also perhaps SMTP, IMAP, FTPS, NNTP, etc).

This may be your opinion, but what's the representation of XMPP etc. software maintainers at the CAB?

[throw0101a]

>> [citation needed]

> My citation is the membership of the CAB.

It is a single member of the CAB that is insisting on changing the MAY to a MUST NOT for clientAuth. Why does that single member, Google-Chrome, get to dictate this?

Has Mozilla insisted on changing the meaning of §1.3 to basically remove "other relying‐party software applications"? Apple-Safari? Or any other of the "Certificate Consumers":

* https://cabforum.org/working-groups/server/#certificate-cons...

The membership of CAB collectively agree to the requirements/restrictions they places on themselves, and those requirements (a) state both browser and non-browser use cases, and (b) explicitly allow clientAuth usage as a MAY; see §7.1.2.10.6, §7.1.2.7.10:

* https://cabforum.org/working-groups/server/baseline-requirem...

[pjc50]

> CAs want to sell certificates for everything under the sun

A serious problem with traditional CAs, which was partly solved by Let's Encrypt just giving them away. Everyone gradually realized that the "tying to real identity" function was both very expensive and of little value, compared to what people actually want which is "encryption, with reasonable certainty that it's not MITMd suddenly".

[sam_lowry_]

No. These are just certificates that happen to be used predominantly in HTTPS context and Google tries to tie them exclusively to the HTTPS context.

[franga2000]

Where did you get that idea? These certs have always been intended for any TLS connection of any application. They are also in no way specific or "designed for" HTTPS. Neither the industry body formed from the CAs and software vendors, nor the big CAs themselves are against non-HTTPS use.

From https://cabforum.org/

> Welcome to the CA/Browser Forum > > The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and suppliers of Internet browser software and other applications that use certificates (Certificate Consumers).

From https://letsencrypt.org/docs/faq/

> Does Let’s Encrypt issue certificates for anything other than SSL/TLS for websites? > > Let’s Encrypt certificates are standard Domain Validation certificates, so you can use them for any server that uses a domain name, like web servers, mail servers, FTP servers, and many more.

[dijit]

You’re like, so wrong.

Are we really at an age where people don’t remember that SSL was intended for many protocols, including MAIL?!

Do you think email works on web technology because you use a web-client to access your mailbox?

Jesus christ, formal education needs to come quickly to our industry.

[bux93]

PKI certificates weren't even intended for SSL, it predates even that.

X.509 was published in November 25, 1988 ; version 3 added support for "the web" as it was known at the time. One obvious use was for X.400 e-mail systems in the 1980s. Novell Netware adopted x.509.

It was originally intended to use with X.511 "Directory Access Protocol", which LDAP was based on. You can still find X.500 heritage in Microsft Exchange and Active Directory, although it's getting less over time and e.g. EntraID only has some affordances for backward compatibility.

[hulitu]

> Jesus christ, formal education needs to come quickly to our industry.

It just went away, upset. It might never come back.