There are but this assumes that services like the transparency log servers and LetsEncrypt are not being legally compelled to do or not do something.
If a log fails to publish a certificate despite issuing a receipt for it, Chrome's SCT auditing infrastructure can detect that, as it did recently with the Nessie 2023 log: https://groups.google.com/a/chromium.org/g/ct-policy/c/5x1A6... (this was also detected by monitors operated by myself and Cloudflare)
But this is all moot when it comes to XMPP, since XMPP clients don't check for SCTs, and there is no requirement for CAs to log certificates if they don't need to work in non-CT-enforcing clients. Some CAs (e.g. DigiCert) will sell you unlogged certificates - no need to compel them.
tldr: situation is good and improving with browsers, not so much with non-browser clients
But SCT validation would indeed be something we should investigate for the ecosystem, it could be beneficial for certain use cases.
Feel free to contact me (email in profile) or ask here if you want to talk more about this. I use XMPP (thank you for Prosody!) and have been involved in the CT space for many years now.
This is fine. If you're using a tool that's connecting to the internet, you probably need to monitor for updates anyway.
I'd like to see a separate package, similar to Mozilla's `ca-certificates`, but for CT that can be updated independently of the actual useragent.
People should do this, but in practice it often doesn't happen - as witnessed by the Appmattus library fiasco earlier this year.
> I'd like to see a separate package, similar to Mozilla's `ca-certificates`, but for CT that can be updated independently of the actual useragent.
Considering how slowly updates to the various ca-certificates packages propagate, this would be absolute disaster for CT.