Do *NOT* remove TLS Client Auth EKU!

Feature Requests
104

This claim surprises me, and does not match my experience.

I'm sure there's some software out there that will use the server certificate by default when acting as a client, but I'd expect that most of the time it'd be possible to configure it otherwise.

6 Likes
105

Like it or not the CA/BF and Chrome Root Program are targeting exactly the same group of CAs. Everyone else doesn't care about them anyway.

however it looks like Digicert is taking matters into it's own hands and trying to push a X9 PKI. They also explain why having clientAuth and serverAuth in the same cert is valuable and all. Maybe their word is more understandable to you all...

I'd still be interested how the Chrome Root Program wants to handle all of the eIDAS CAs then. They're issuing website certificates that are also used for server-to-server API requests in PSD2 after all...

107

Yeah, I knew about the Apple proposal to lower the max lifetime to 398 not passing and then them making it part of the root program requirements. It definitely shows who has the real power in WebPKI.

But that's a case of Apple seeking discussion and a vote on the CA/B Forum and then bypassing the forum after CAs made the (short-sighted) decision to reject the ballot.

Apple again submitted a ballot to gradually lower the certificate maximum lifetime to 47 days. And Google submitted a ballot for requiring MPIC.

I don't think these started as root requirements. So, it seems like browsers at least occasionally try to get requirements into the BRs first. But that didn't happen for clientAuth EKU removal.

108

Because ClientAuth is still going to be allowed under the BRs and some CAs will continue to support it. It would be a much bigger change to remove it from the BRs.

Chrome’s root program is smaller than the full Web PKI, just used by Chrome. As you’ve all noted, the set of CAs contained in a typical Linux trust store are used for things beyond just what Chrome does.

I would suggest this discussion should move to the CCADB public mailing list, which is the best place to communicate with the root programs and their requirements.

5 Likes
109

This is why I added this as a change request: to mandate CAs to do it.

110

As I already wrote (!), sendmail does support separate files,
but e.g. Jabber servers generally don’t (verified for the one
I use).

111

That's what I was doubting, but if that's the case then that explains it. Thanks!

1 Like
112

Then maybe this should be a feature request towards your Jabber server.

5 Likes
113

Not in time for this. Even assuming people run current operating
systems (which they don’t, for reasons), a vast majority won’t see
anything that gets implemented within the year before early-to-mid
2028, due to distro release cycles.

114

I don't know that there is a big overlap in the Venn diagram of 'CAs who will still issue with clientAuth because they don't care about Chome' and 'will sell or make available a certificate to subscribers' and maybe 'CAs who put the effort in to stay in all the none-Chrome trust stores'.

clientAuth is going away for publicly-trusted certificates, and in barely 12 months. I would suggest using that time to migrate away or find alternative solutions, instead of making (I believe futile) attempts to change Google policies.

2 Likes
115

I don't understand how you accept your Jabber server to not support this (at least not for the forseeable future), while on the other hand you demand a CA to adjust to your expectations.

6 Likes
116

They already have their own EUTL trust store and do not rely on copying Chrome's or Mozilla's trust store unlike most Linux distros.

2 Likes
117

I put together a quick script to find certificates trusted by Apple/Mozilla/Microsoft that aren't trusted by Chrome. It doesn't take into account cross signs but it does show some relevant CAs.

Apple and Microsoft include CAs like:

  • SSL.com Client ECC Root CA 2022 (in Apple/Microsoft)
  • HARICA Client ECC Root CA 2021 (in Apple/Microsoft)
  • GlobalSign Client Authentication Root E45 (in Microsoft)

Just based on looking at the cert names, Mozilla doesn't seem to include single purpose client auth roots.

Still, there are a lot of root certificates in there where the CA might decided to keep issuing certs with the client auth EKU.

Output and script here so people can check it out (and point out any mistakes :stuck_out_tongue:) Root program report ¡ GitHub

118

I don’t understand why it’s so hard for people to get the expectation
that THINGS THAT CURRENTLY WORK JUST CONTINUE WORKING, i.e. don’t
break existing users, period.

Even the Linux kernel doesn’t do it, even if people occasionally try.

119

SSL 3.0, TLS 1.0, SHA-1 certificates, ... also worked at some point, but are largely not supported anymore today.
The Internet is not a static environment.

5 Likes
120

If the public WebPKI was never willing to break existing systems, we'd still be in a world where publicly trusted CAs issued certificates for localhost and used encryption algorithms that are now known to be weak.

Yes, change makes things more difficult. But the only thing worse than change to make things more secure is a lack of change to make things more secure. And those are basically the options.

6 Likes
121

Are you actively discussing this issue at any XMPP, XSF, and/or Jabber forums?

I think that entire community is best engaged to figure out a way forward.

Let's Encrypt staff has been very clear on their plans. Involving the experts for your server products is likely more productive.

@agowa post of DigiCert's explanation of X9 PKI targeted at financial systems is an excellent example of a group focused on building a solution for their needs. Seems to me that the XMPP, XSF, and Jabber community needs to get together as well.

4 Likes
122

How does this make things more secure? It doesn’t.

123

You can read about the reasons from Chrome at Moving Forward, Together

Further questions on that subject should be directed to them.

6 Likes
124

That would not help, as this affects more than one use case,
and we don’t even know all current use cases that are affected
BECAUSE THIS ALWAYS HAS JUST WORKED.