They're more likely to put in the least amount of effort or care the least about the reasons how the header is used later on.

Other anti-spam implementations also punish the lack of Message-ID. There are tools online that highlight this as an issue.

This here is a trivial case of simply not testing deliverability at all.

The biggest war on small providers is waged by other small providers. They can be ancient and outdated or simply extremely picky. Which makes everything Google or others require a piece of cake, which it actually kinda is.

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

What exactly do you mean with "WebPKI"?

The PKI system was designed independently of the web and the web used to be one usecase of it. You're kind of turning that around here.

The current PKI system was designed by Netscape as part of SSL to enable secure connections to websites. It was never independent of the web. Of course PKIs and TLS have expanded beyond that.

"WebPKI" is the term used to refer to the PKI used by the web, with root stores managed by the browsers. Let's Encrypt is a WebPKI CA.

The idea of a PKI was of course designed independently, there are many very large PKIs beyond WebPKI. However the one used by browsers is what we call WebPKI and that has its own CAs and rules.

You're trying to make it sound like there has ever been some kind of an universal PKI that can be used for everything and without any issues.

> What exactly do you mean with "WebPKI"?

WebPKI is the name of a specific PKI system, where PKI us a generic term for any PKI.

Basic accountability doesn't pay for the infrastructure required for a separate root.

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.

Code can just ignore the EKU. Especially if the ecosystem consists of things that are already using certificates in odd ways, as it shouldn't be making outgoing connections without it in the first place.

SVGs are just the tip of the iceberg of how hard it is to sanitize email content. There aren't any purpose-built good libraries for email sanitization either. Something that would handle SVG, CSS, HTML, everything.

Put it in an iframe with a Content-Security-Policy header?

Some providers do that.

But you still have to dynamically allow or disallow external content such as images. It also makes any operations based on the content more convoluted. Like adding event invites to calendar and so on.

Popular Linux distributions also use HTTP CDNs. Even though the content is always signed, it still exposes the HTTP stack, signature verification code and a bunch of the application logic to the attacker.

Apt has had issues where captive portals corrupt things. GPG has had tons of vulnerabilities in signature verification (but to be fair here, Apt is being migrated to Sequoia, which is way better).

But these distros are still exposing a much larger attack surface compared to just a TLS stack.