I had no idea EU had mandated this from software developers/browser authors. I hope they can kindly go fuck themselves w.r.t. non-EU software not sold in EU (but merely available online for download by anyone).
It’s so funny how Americans seem to assume it’s the natural order of things that the whole world has to comply with American regulation, but lo and behold if the EU dares to have laws of its own!
For nearly a decade, I've been occasionally tracking how many of the Cloudflare top-2K sites (earlier: Alexa) respond with an EV cert. And then also pull the SSL Labs score to see if there was any correlation.
Great work, did a similar analysis recently but only for the top 50, and in fact none of the top 50 had an EV at the time of the survey.
I believe the only possible advantage of an EV is not a technical one, but rather an organizational one: it encourages the use of a single keypair on each server because Wildcard coverage is not allowed (although multi-domain is allowed). For what appear to be non-technical reasons, I have seen many entities copying their keypairs for Wildcard certs between servers, even between business critical on-prem backends and cheap shared hosting or budget VPS, or handing the keypair over to a contractor via email.
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.
> The Stripe we are all familiar was incorporated in Delaware, so there was not a collision. But both companies were described by a browser as “Stripe, Inc.”
As I recall, EV certificates also had the 'problem' that a lot of companies trade under names that aren't their full legal name, making the EV cert confusing. To use modern examples, twitter.com having an EV cert for "Space Exploration Technologies Corp", google.com having an EV cert for "Alphabet Inc" and suchlike.
Maybe we should do registered trademarks? For disambiguation location and class of goods/services might still be needed, but a certificate showing as “Google (search engines, US)” (taken from [0], picking Nice class 42) would be recognisable to many users, I guess.
Have seen some entities request a large number of EV certs (more than 10, sometimes up to 40) for subdomains under a single domain. At the same time, they are requesting OV Wildcard certificates for the main domain, which have overlapping coverage with the EV certs. These entities do not have any regulatory requirements to use EV as far as I know.
Is there any point in doing this?
The overlap from the Wildcard would seem to nullify any theoretical advantage of the EV cert, given that both will be recognized as valid certs that can cover the subdomains. This in addition to the fact that browsers do not treat EV, OV and DV certs differently in any significant user-facing way since many years now.
Frequently these entities also use Let's Encrypt DV certs on some subdomains alongside their EV certs, so of course a CAA record cannot be used to limit emissions to the CA which emitted the EVs.
Can anyone think of a legitimate technical motivation to use EV certs alongside an overlapping Wildcard OV and various DVs?
I remember when these rolled out.. it was just an obvious cash grab by cert vendors, trying to create a trust-badge in collusion with browsers.
Back then, cert vendors would try to sell you on "premium" certificates.. telling you that cheap ssl certificates weren't good enough, so you needed to pay for $100-300+/yr certificate, and you could show to your visitors by displaying silly trust seals like the "Thwarte Seal".. as if customers would know who the hell Thwarte is.
Then this EV seal was launched, displaying what was essentially a trust seal in the browser.. and these same vendors would charge $500+/yr for it.
I can't express how great it is that EV certs died.
The entire premise of Bimi is just EV certs all over again, wrapped up in an email security blanket. Naturally it starts with a cartel of limited approved CAs.
I recognize that they had a lot of issues and I'm glad the implementation of EV certs that we had died out, but I've always thought the concept itself wasn't a bad one. For stuff like banking or government websites, it would be nice to have them tied to a legal entity instead of purely just a domain name.
In theory we could even limit it so that only a given country's CAs can sign entities under that country (somewhat mitigating the whole eMudhra thing...)
It does feel like kind of a shame sometimes, there's a lot of stuff that would be possible with TLS/certs/webpki that we don't really explore. Mutual TLS, for instance. I get why, and I'm as happy as anyone that Let's Encrypt exists, but sometimes it feels unfortunate that we've settled into the comfort zone of "get a domain name, pull an LE cert for it" and don't often do much else with the technology and all the CA infrastructure.
This is an interesting thread, thanks for linking it! Though I felt a lot of the author's argument seemed a little circular / "dividing up trust is bad, because it's bad" right up until the end, where they summarized it nicely:
> It strives to draw borders around the (secure) Internet, and to acknowledge that what you do in your own borders, to your own users, is an issue between you and them. I don't think that's a good state for anyone to be in.
I am definitely sympathetic to this argument, but IDK, I don't think the current state we're in is great either. We've known for ages that the global CA ecosystem is messy, and I think a lot of people were just waiting for something like the "4 incident" to happen. We would all prefer if the audit requirements (and measures like CT and such) were stringent enough that no CA could be a bad guy and everyone was secured globally, but it doesn't seem like that's what we're getting.
It's a hard call for sure, I don't know enough about it to have a strong opinion. My gut instinct is still that I'd prefer to live in a nameConstraints world over the current one where any CA in my /etc/ssl can sign/MiTM anything. (But CT certainly does go a long way towards mitigating that.)
> any particular reason to think that the Stripe problem is solvable
I'd imagine, in a "proper implementation":
- It would probably only make sense for orgs that actually "need" EV certs to get them. I'm not sure how you'd decide this, but I think most users would agree they should be reserved for banks and gov and such, not random LLCs with a few hundred dollars.
- Trademark law is somewhat designed for this sort of thing (confusing/overlapping company names), so maybe that could play a part. Nowadays you could maybe include a company logo in the "badge" as well.
- EV certs would still satisfy nonrepudiation, in a way. You'd have to be pretty bold to run a phishing site under a company registered in your users' country under your legal name.
> EV certs would still satisfy nonrepudiation, in a way. You'd have to be pretty bold to run a phishing site under a company registered in your targets' country under your legal name.
I don't think that would be the failure mode. It'd be a phishing site that uses a compromised EV cert issued for an obscure small bank in a far away country purporting to be a major brand bank in your own country, taking advantage of the asymmetry in cybersecurity budget between those two entities. Users would have to actually check the EV cert DN every time (unlikely so successful for a phisher then) or rely on things orthogonal to EV certs like pinning.
> It'd be a phishing site that uses a compromised EV cert issued for an obscure small bank in a far away country purporting to be a major brand bank in your own country
EV certs when they were around showed a big green badge by the URL with the entity's legal name. Presumably this would work similarly, so you'd see ObscureBankInc and not Chase or Citi or whoever.
It'd probably make sense to add a flag indicator, or otherwise warn when the cert is from a country other than the users' own.
Similar to HSTS Preload List, a domain owner can enroll the domain into an "EV only" program on a yearly basis, such that the list of "EV only" domains will be preloaded into major web browsers. Browsers will refuse to accept any certificate for the domain which is not EV. The browser UI does not need to change.
25 comments
[ 5.1 ms ] story [ 46.3 ms ] threadIf anyone is interested:
https://github.com/mieko/greenbar
I should probably chart out the changes throughout the years, but this was more of a curiosity hack.
I believe the only possible advantage of an EV is not a technical one, but rather an organizational one: it encourages the use of a single keypair on each server because Wildcard coverage is not allowed (although multi-domain is allowed). For what appear to be non-technical reasons, I have seen many entities copying their keypairs for Wildcard certs between servers, even between business critical on-prem backends and cheap shared hosting or budget VPS, or handing the keypair over to a contractor via email.
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).
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.
As I recall, EV certificates also had the 'problem' that a lot of companies trade under names that aren't their full legal name, making the EV cert confusing. To use modern examples, twitter.com having an EV cert for "Space Exploration Technologies Corp", google.com having an EV cert for "Alphabet Inc" and suchlike.
[0]: https://branddb.wipo.int/en/brand/US502016086912587
Have seen some entities request a large number of EV certs (more than 10, sometimes up to 40) for subdomains under a single domain. At the same time, they are requesting OV Wildcard certificates for the main domain, which have overlapping coverage with the EV certs. These entities do not have any regulatory requirements to use EV as far as I know.
Is there any point in doing this?
The overlap from the Wildcard would seem to nullify any theoretical advantage of the EV cert, given that both will be recognized as valid certs that can cover the subdomains. This in addition to the fact that browsers do not treat EV, OV and DV certs differently in any significant user-facing way since many years now.
Frequently these entities also use Let's Encrypt DV certs on some subdomains alongside their EV certs, so of course a CAA record cannot be used to limit emissions to the CA which emitted the EVs.
Can anyone think of a legitimate technical motivation to use EV certs alongside an overlapping Wildcard OV and various DVs?
Back then, cert vendors would try to sell you on "premium" certificates.. telling you that cheap ssl certificates weren't good enough, so you needed to pay for $100-300+/yr certificate, and you could show to your visitors by displaying silly trust seals like the "Thwarte Seal".. as if customers would know who the hell Thwarte is.
Then this EV seal was launched, displaying what was essentially a trust seal in the browser.. and these same vendors would charge $500+/yr for it.
I can't express how great it is that EV certs died.
In theory we could even limit it so that only a given country's CAs can sign entities under that country (somewhat mitigating the whole eMudhra thing...)
It does feel like kind of a shame sometimes, there's a lot of stuff that would be possible with TLS/certs/webpki that we don't really explore. Mutual TLS, for instance. I get why, and I'm as happy as anyone that Let's Encrypt exists, but sometimes it feels unfortunate that we've settled into the comfort zone of "get a domain name, pull an LE cert for it" and don't often do much else with the technology and all the CA infrastructure.
ccTLD name constraints are an old idea, back in the news again lately for obvious reasons, and the same arguments against them still apply: https://groups.google.com/g/mozilla.dev.security.policy/c/pF...
Are there other use cases besides those that you think the Web PKI should support?
This is an interesting thread, thanks for linking it! Though I felt a lot of the author's argument seemed a little circular / "dividing up trust is bad, because it's bad" right up until the end, where they summarized it nicely:
> It strives to draw borders around the (secure) Internet, and to acknowledge that what you do in your own borders, to your own users, is an issue between you and them. I don't think that's a good state for anyone to be in.
I am definitely sympathetic to this argument, but IDK, I don't think the current state we're in is great either. We've known for ages that the global CA ecosystem is messy, and I think a lot of people were just waiting for something like the "4 incident" to happen. We would all prefer if the audit requirements (and measures like CT and such) were stringent enough that no CA could be a bad guy and everyone was secured globally, but it doesn't seem like that's what we're getting.
It's a hard call for sure, I don't know enough about it to have a strong opinion. My gut instinct is still that I'd prefer to live in a nameConstraints world over the current one where any CA in my /etc/ssl can sign/MiTM anything. (But CT certainly does go a long way towards mitigating that.)
> any particular reason to think that the Stripe problem is solvable
I'd imagine, in a "proper implementation":
- It would probably only make sense for orgs that actually "need" EV certs to get them. I'm not sure how you'd decide this, but I think most users would agree they should be reserved for banks and gov and such, not random LLCs with a few hundred dollars. - Trademark law is somewhat designed for this sort of thing (confusing/overlapping company names), so maybe that could play a part. Nowadays you could maybe include a company logo in the "badge" as well. - EV certs would still satisfy nonrepudiation, in a way. You'd have to be pretty bold to run a phishing site under a company registered in your users' country under your legal name.
I don't think that would be the failure mode. It'd be a phishing site that uses a compromised EV cert issued for an obscure small bank in a far away country purporting to be a major brand bank in your own country, taking advantage of the asymmetry in cybersecurity budget between those two entities. Users would have to actually check the EV cert DN every time (unlikely so successful for a phisher then) or rely on things orthogonal to EV certs like pinning.
EV certs when they were around showed a big green badge by the URL with the entity's legal name. Presumably this would work similarly, so you'd see ObscureBankInc and not Chase or Citi or whoever.
It'd probably make sense to add a flag indicator, or otherwise warn when the cert is from a country other than the users' own.
For example, a government could be an intermediate CA, and have it technically limited only to issue certificates for `*.gov.CCTLD` domains.
EV Preload List
Similar to HSTS Preload List, a domain owner can enroll the domain into an "EV only" program on a yearly basis, such that the list of "EV only" domains will be preloaded into major web browsers. Browsers will refuse to accept any certificate for the domain which is not EV. The browser UI does not need to change.