[Avamander]

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

[xg15]

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?

[Avamander]

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.

[account42]

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.

[Avamander]

Relying on an accidental feature and its removal causing work is a perfect example why it shouldn't be there in the first place.

The XMPP community can continue to adapt other infrastructure for their purposes and do the thing they do. It does not mean it has to be catered to.

[ge0rg]

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.