undefined | Better HN

0 pointsge0rg2mo ago0 comments

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.

0 comments

Avamander2mo ago

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

xg152mo ago

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?

Avamander2mo ago

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.

account422mo ago

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.

1 more reply

ge0rgOP2mo ago

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.

j / k navigate · click thread line to collapse

0 comments

Avamander2mo ago

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

xg152mo ago

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?

Avamander2mo ago

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.

account422mo ago

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.

1 more reply

ge0rgOP2mo ago

j / k navigate · click thread line to collapse