galadran

All the design needed was for the browser to check the TLS cert and the QWAC cert covered the same domain name. Instead, folks at ETSI insisted very stubbornly on the signature from the QWAC over the cert used in TLS - which is an annoying complication for site operators - and provides little additional benefit.

I'd also like to see the EU encode more information in these certs. Knowing a company's address is not very useful (IMO), but a machine readable label that the site is regulated by $COUNTRY_NAME financial or medical regulator would be a much more useful signal.

Good luck in your endeavours!

However, there are obligations to display 2-QWACs if sites choose to use them. Their keys are not used to authenticate web domains or encrypt web traffic.

Disclosure: I was Mozilla's lead for this effort and also helped design 2-QWACs (for my sins).

https://bugzilla.mozilla.org/show_bug.cgi?id=2029458

Over 10 years ago, Mozilla shipped OneCRL [1]. We remediated this incident in a couple of hours for Firefox users who were protected automatically without the need for updates. Chrome, Apple and Microsoft have similar tooling. Since then, we've built more advanced tooling to handle revocation at scale for leaf certs (CRLite [2]).

However, for the rest of the ecosystem, there has been little to no investment in revocation and for those clients, this is a massive problem. Hopefully, we'll see folks invest now. Efforts like upki [3] look promising.

[1] https://blog.mozilla.org/security/2015/03/03/revoking-interm...

[2] https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...

[3] https://github.com/rustls/upki

The Recommended flag is set for X25519MLKEM768. It is not set for any of the pure PQ key exchanges.

https://www.iana.org/assignments/tls-parameters/tls-paramete...

All of these libraries also support the hybrid forms, which have different codepoints and are used by default. Nothing in the IETF process has any bearing on this.

There are already codepoints assigned for MLKEM 512/768/1024 (0x0200, 0x0201, 0x0202) and nearly every major library supports it already:

  - OpenSSL (ML-KEM-512/768/1024)
  - BoringSSL (ML-KEM-1024)
  - NSS (ML-KEM-1024)
  - AWS-LC (ML-KEM-512/768/1024)
  - Rustls (ML-KEM-768/1024)
  - s2n-tls (ML-KEM-1024)
  - Bouncy Castle (ML-KEM-512/768/1024)
  - Botan (ML-KEM-512/768/1024)
  - GnuTLS (ML-KEM-768/1024)
  - WolfSSL (ML-KEM-512/768/1024)

Shorter post: https://blog.mozilla.org/en/privacy-security/keeping-the-web...

Recognition means that web browsers are required to ensure support and interoperability for the QWAC for the sole purpose of displaying identity data in a user-friendly manner. *Recognition of QWACs implies that browsers shouldn't question the origin, integrity or data in the certificate*.

However, the requirement to recognise QWACs does not affect browser security policies and leaves web browsers free to preserve their own procedures and criteria for encryption and authentication of *other certificates*.

https://ec.europa.eu/commission/presscorner/detail/en/QANDA_...

There's a difference between certificates distributed with the OS and certificates added to the OS by a user. Right now Firefox ignores both.

This change ONLY picks up the certificates added to the OS by a user. Firefox will continue to ignore the certificates included with the OS store by default.

The open letter signed by 300+ researchers, professors and experts.

In this case, Cloudflare are acting as the ECH provider and as they already host the websites, they already see the connection plaintext.

Deeply subjective. Rust has been the most loved language on Stack Overflow for 5 years in a row now.

> add a new huge dependency

Sure, but setting up Rust is much much easier than GCC with all the trimmings.

> As an exemple, there is a common package in python that decided to start having their module in Rust instead of C. Now a lot of users of the module are pissed off, with good reason, because you can't build/install the module anymore in a little bit older or non conventional distributions.

Assuming you are referring to pyca, you are mistaken and there has been a lot of misinformation about the change. Rust support is needed to build the module, but not install it. Pyca works just fine for users without rust and works everywhere rust does. Users on niche CPU architectures which haven't been sold commercially for 15+ years were the only ones impacted.