Clarification: Browsers or other user-agents are not required to trust QWACs for use in TLS. We fought very hard for this.
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).
2-QWACs are awesome! Thank you for your contributions!
Though I don't understand why they would atone for any sins. IMHO, you created the website identity infrastructure for the agentic web...
And yes, I hope I didn't imply that QWACs are trusted by default for TLS. 1-QWACs would have to come from an existing trusted CA to be recognized by the browser.
Ah, the sins are more to do with the design of 2-QWACs.
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.
Very interesting history, thank you for sharing. I had wondered about the design choices there.
Agree that the next step for 2-QWACs is additional corporate data (professional licensure like you mentioned, incorporation date) and eventually arbitrary claims vetted by a QTSP.
For an average human user, these additional claims are nearly useless since they're so buried in the browser UI...and even if they were more prominent, they wouldn't be of much benefit, as the EV history has shown.
But for an agent that knows to look out for these signals, extensible 2-QWACs will be extremely valuable.
Why do agents need any of this cryptographic infrastructure? Can't they just check on the certifying authority's website whether an entity is legitimate?
- If by certifying authority you mean a CA/Trust Service Provider, they don't generally publish client information in a central location.
- If you mean the actual jurisdictional authority, there are thousands and public records are all over the place.
- Websites aren't generally part of corporate filing records. So the agent would still need a way to connect the website to the corporation even after checking the legitimacy of the corporation.
- Serving the structured info in an HTTP header that is cryptographically verifiable by the browser itself (via its trusted roots) essentially serves as a distributed database for website identity, which eliminates the need for each agent to come up with its own ad-hoc verification system on the fly (and all the additional fetches that come along with it)
Can you give a concrete example of the kind of claim you think QWACs would be useful for verifying, that can't be addressed just as well with existing protocols?
But some organization has to check all that stuff, confirm that it's accurate, and then issue the certificate, right? So what's lost from having that organization just have a website that maps that information to domain names?
[Edit: I was inattentive and replied twice in different ways, thinking they were to different parent comments; I've now merged my thoughts and edited them to be more coherent.]
> reported
This is Mozilla's own discussion of the issue, though. There's mention of
If it was done, then I think we deserve answers about why it took Google almost 8 months to release a new version of a common dependency, applying a security patch (and no other changes!) when the vulnerability was known at least 6 months ago (and possibly the full 8 months ago) to cause RCE.
If I'm understanding the report correctly, the patch was applied in Firefox's vendored copy within days, and available in 151 and I guess some 150.0.x release. And also they were supposedly beaten to the punch:
> Probably we should update to cfa184a997ac19454d5a3ae97f6d600aac2445a6 which was rolled into chromium 2 weeks ago. If there are other recent sec fixes this would pick them up
It seems even more embarrassing if chromium got the patch but Chrome didn't. And if Chrome did, then it's that much more appalling not to see a patched separate release for so long.
(I was confused trying to go through the technical details, though: the "affected code" seems to have very little overlap with the code actually altered by the patch.)
The impact of this incident is very unevenly spread.
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.
Firefox Mobile 158.0 on Android 17 (Pixel 7) connects to all the demo sites with zero warnings. Any idea why the "automatic protection without updates" doesn't seem to be working with that combination?
Pixel 10 with 158.0.1 still connects to the emSign ones, even though the patch notes for 158.0.1 mention that it updates the CRL for those without 'Remote Improvements' enabled?
edit: Disabling all the eMudhra CAs in Android settings does nothing, cool?
edit: I guess there's no way to manually ask for CRL update, cool??
edit: Gave up and reinstalled Firefox. Seems to be fine now.
I'm hoping some organizations will step forward to fund work on this.
(Note that curl on Ubuntu 26.10 now has CRLite support baked via upki -- unfortunately that doesn't help with this because AIUI CRLite is only for end entities, not for intermediate certificates.)
It's very inconsistent for me even on just Firefox. On multiple systems running different instances of Firefox, checking with https://emudhra.we-have-a-problem.com/:
One blocks everything; one blocks 6 out of 12; one blocks the other 6 out of 12; one blocks nothing.
You mean the response was uneven. The impact was a complete and total potential compromise of literally everyone. Every domain. Every client using one of the public root programs. Every user of those clients.
I mean, it's an emergency, but the acute severity is debatable; many times a month the major browsers quietly deal with vulnerabilities that yield attackers direct control of victim computers; here, attackers get the ability to spoof websites if they're in a position to hijack connections.
The middlebox situation, with non-updatable roots, is very annoying. But middleboxes also have unfixable RCEs, so...
It's totally fair to evaluate different projects by how well positioned they are to update their WebPKI trust anchors. I'm just saying, keep perspective.
So it other words, it allowed attackers to do the one thing that Web PKI is supposed to prevent.
Being able to quickly update trust roots is at best a hack to paper over the issue when there is no good reason why every podunk CA should have authority to generate certificates for every domain in the first place. It's an inexcusable design flaw. Or a feature that gives power to root stores at the expense of everyones security, from the perspective of the root store operators.
Keep in mind that a _lot_ of software out there uses TLS as its only trust anchor for updates, commands or similar.
This can and will be weaponized for take-overs of systems. They will be of the consumer kind, but they will also be of the industry kind. Let's pray that they will not be of the state or military kind.
I feel like my takeaway here is that things that are not connecting software written by a wide group of people should not rely on the root CAs.
We often use TLS to connect software run by the same organization because it is convenient, but why are we giving random CAs the ability to issue certs for these cases?
You mean you and Chrome stopped supporting normal CRLs and OCSP, replacing (for normal users) these distributed-trust technologies with central lists controlled by browsers
OCSP stapling works fine technically, which is one reason it's still available in both browsers via enterprise policy. LE dropping support for it and browsers having insufficient courage to hard-fail doesn't make the model broken. It instead makes the ecosystem broken.
Just another step towards a tiny number of browser vendors and infrastructure companies controlling the internet.
Which is to say, sub-CAs in itself are a giant loophole that needs plugging. Especially since AFAIK nobody is bothering with name constraints (RFC5280 section 4.2.1.10).
eMudhra is also a root CA operator. One root CA operator cross-signing another root CA operator is a good thing actually, and it's what allowed Let's Encrypt to work before their root certificate was widely trusted.
Issuing sub CAs to non-root operators has historically been a big loophole though it's not as bad these days since multiple root programs now require approval before CAs can do it.
Didn't Let's Encrypt have to jump through all sorts of hoops to prove they were competent and trustworthy before that happened?
Now it's coming out these guys used "4" as a private key. That's a crazy amount of incompetence and malfeasance. Did they vibe-code a CA? HOW DOES THIS HAPPEN? I am dumbfounded.
You couldn't even do this if you installed Microsoft Small Business Server 2008 today, unpatched, with the CA on default settings.
The reason nobody bothers with NCs is because they don't work very well in practice. They also have their own baroque matching rules that are not intuitive if you're from the land of UNIX globs.
(In fairness this is a self-fulfilling prophecy: a lot of validators handle NCs poorly or not at all, so there's no impetus to rely on them. But that's not something we can really save in the Web PKI's current state.)
> But that's not something we can really save in the Web PKI's current state.
I agree with your assessment but it's not an excuse to give up without trying. I hope this is just because I'm not looking in the right places, but I don't see people trying.
What really makes me salty is that there was enough energy to mess with the rules around EKU, the primary effect of which is that non-browser software is now starting to just ignore the EKU bits. Even if it would've amounted to nothing, I'd really rather that effort had gone into NCs.
I think a lot of people have tried! The reason EKUs stuck where NCs haven’t is because EKU rules are simple (in relative terms) and OpenSSL didn’t make as much of a mess out of them.
I can't help but read your post as "OpenSSL didn't make a mess of EKUs so the CA/B had to fill that role instead" :/
(I really am salty about the EKUs. In a few years the EKU field will just be useless, due to operational annoyance driving devs to ignore it. Except in browsers of course.)
They hold intermediate certificates issued by TWO different root CAs, neither of which they operate.
So two separate entities didn't bother to read their certificate policy or inspect their operations. Have we not learned anything from past mistakes?
Roots should be responsible for all their sub-CAs, full stop. If they don't trust them enough to accept that responsibility, then the system is broken.
The screening process has been more involved in that since around the late 2000's. I wouldn't call 20 years "very recently," especially in the context of the history of the web.
circa 2007 I was looking over a college textbook on computer networking that I saw at a family member's house. It still said "While networks are inherently unreliable, it's not a stretch to imagine a future where one can stream video on-demand over a WAN like the Internet"
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).