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.