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. (EDIT: You could also gate them behind some kind of audit or cert like SOC2/ISO, presumably decided per country)
- 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 targets' 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.
If we showed the EV cert DN in the the address bar next to the domain instead of hiding it in a place that takes two mouse clicks to reach we could expect at least a portion of victims to notice. I vaguely recall some browsers might have even been doing that once upon a time?
Additionally, the browser could show a warning if a ccTLD is served with an EV cert of an entity outside that country. Doesn't help the US because of the obscurity of .us, but useful for the rest of the world
> If we showed the EV cert DN in the the address bar next to the domain instead of hiding it in a place that takes two mouse clicks to reach we could expect at least a portion of victims to notice.
The article covers this. Apparently research demonstrated that the number of users who would notice is not significant.
> 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.
Would be cool, but IDK how much it'd help. The modern threat model it seems is very much phishing / getting people to enter creds onto sites that they think belong to their bank or whatnot, but are in reality different, unrelated domains. Since the domain is different HSTS, etc don't apply.
Training people to "look for the big green badge and make sure it says JPM Chase, USA" seems easier than "you have to make sure it's chase.com EXACTLY". But in reality the solution is to use a password manager with URL matching (or passkeys... But ehh)
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.
The browser vendors, I think, were at least making a good-faith attempt to address a real security problem; it's not like they made any money from EV certificates. Even if it was inevitably going to be marketed somewhat predatorily, and ultimately didn't work out.
It was a bargain. The CAs wanted EV and the browsers wanted the BRs (Baseline Requirements).
Before the BRs certificate validation quality had been on a dramatically steep race to the bottom. The BRs immediately stopped that, if your certs didn't meet the BRs that's an obvious red line, everybody can see - this was now the bottom. But they also (and this perhaps was less obvious) were incrementally improved.
From the outset the intent was to keep meeting, at first to nail down everything in the agreement, but then to revise and improve the Baseline Requirements. Although there are some changes to make the lives of CAs easier, the vast majority of changes just tighten things up.
For example the original BRs want to stamp out the practice of just making up DNS names. It seems crazy today, but in 2010 that's really a thing "legitimate" CAs would do and your browser would accept it. made-up.name.in.example "works" fine, a CA can issue the certificate, you can use /etc/hosts or equivalent and it all checks out - even though that's clearly nonsense - who could get such a cert? Anybody. So what possible value does it have? Well, somebody paid for the certificate.
After the BRs go into force in July 2012 that's against the rules. It doesn't stop happening immediately, but it is now clearly forbidden, so at least they say "Sorry, won't happen again" and cross fingers they actually mean it.
Likewise, the original BRs say certificates must only last 60 months. That seems like forever - and it is - but at the time some sites had 10 year certificates. Hey, if you agreed to pay $500 for a certificate, on condition that it's valid for a decade, what self-respecting sales person wouldn't sell that?
The BRs say not to issue with terrible keys (yes, I know, that's ironic given what we found out this month) and lots of other basic "Duh obviously" stuff which alas was not apparently obvious enough that it wasn't news to at least one CA.
By 2015 the BRs are telling CAs to stop issuing with SHA-1 hashes. They don't actually meet the deadlines in that document, but they're pretty close, I'm fairly sure that nobody actually got a bogus cert (as had definitely happened for MD5) though it may have been closer than we'd have liked.
This is a success story, and EV certs were a very small price to pay.
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?
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 unique 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.
> 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.
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 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!
Yes. The entire internet is US-shaped. From social networks applying ridiculous puritan beliefs globally to the madness that is the TLD system, DMCA, the CLOUD act… all the way to the NSA spying on non-US citizens to protect themselves.
A Puerto-Rican crypto bro wouldn’t have a career without the USA exerting their will and regulations onto the rest of the world.
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.
There are discussion in CA/B forums for root and intermediate CAs with technically scoped issue policies.
For example, a government could be an intermediate CA, and have it technically limited only to issue certificates for `*.gov.CCTLD` domains.
Do you have any particular reason to think that the Stripe problem is solvable?
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?
> the same arguments against them still apply
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. (EDIT: You could also gate them behind some kind of audit or cert like SOC2/ISO, presumably decided per country)
- 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 targets' 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.
If we showed the EV cert DN in the the address bar next to the domain instead of hiding it in a place that takes two mouse clicks to reach we could expect at least a portion of victims to notice. I vaguely recall some browsers might have even been doing that once upon a time?
Additionally, the browser could show a warning if a ccTLD is served with an EV cert of an entity outside that country. Doesn't help the US because of the obscurity of .us, but useful for the rest of the world
> If we showed the EV cert DN in the the address bar next to the domain instead of hiding it in a place that takes two mouse clicks to reach we could expect at least a portion of victims to notice.
The article covers this. Apparently research demonstrated that the number of users who would notice is not significant.
> 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.
An idea to make EV certs somewhat more useful:
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.
Would be cool, but IDK how much it'd help. The modern threat model it seems is very much phishing / getting people to enter creds onto sites that they think belong to their bank or whatnot, but are in reality different, unrelated domains. Since the domain is different HSTS, etc don't apply.
Training people to "look for the big green badge and make sure it says JPM Chase, USA" seems easier than "you have to make sure it's chase.com EXACTLY". But in reality the solution is to use a password manager with URL matching (or passkeys... But ehh)
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.
The browser vendors, I think, were at least making a good-faith attempt to address a real security problem; it's not like they made any money from EV certificates. Even if it was inevitably going to be marketed somewhat predatorily, and ultimately didn't work out.
It was a bargain. The CAs wanted EV and the browsers wanted the BRs (Baseline Requirements).
Before the BRs certificate validation quality had been on a dramatically steep race to the bottom. The BRs immediately stopped that, if your certs didn't meet the BRs that's an obvious red line, everybody can see - this was now the bottom. But they also (and this perhaps was less obvious) were incrementally improved.
From the outset the intent was to keep meeting, at first to nail down everything in the agreement, but then to revise and improve the Baseline Requirements. Although there are some changes to make the lives of CAs easier, the vast majority of changes just tighten things up.
For example the original BRs want to stamp out the practice of just making up DNS names. It seems crazy today, but in 2010 that's really a thing "legitimate" CAs would do and your browser would accept it. made-up.name.in.example "works" fine, a CA can issue the certificate, you can use /etc/hosts or equivalent and it all checks out - even though that's clearly nonsense - who could get such a cert? Anybody. So what possible value does it have? Well, somebody paid for the certificate.
After the BRs go into force in July 2012 that's against the rules. It doesn't stop happening immediately, but it is now clearly forbidden, so at least they say "Sorry, won't happen again" and cross fingers they actually mean it.
Likewise, the original BRs say certificates must only last 60 months. That seems like forever - and it is - but at the time some sites had 10 year certificates. Hey, if you agreed to pay $500 for a certificate, on condition that it's valid for a decade, what self-respecting sales person wouldn't sell that?
The BRs say not to issue with terrible keys (yes, I know, that's ironic given what we found out this month) and lots of other basic "Duh obviously" stuff which alas was not apparently obvious enough that it wasn't news to at least one CA.
By 2015 the BRs are telling CAs to stop issuing with SHA-1 hashes. They don't actually meet the deadlines in that document, but they're pretty close, I'm fairly sure that nobody actually got a bogus cert (as had definitely happened for MD5) though it may have been closer than we'd have liked.
This is a success story, and EV certs were a very small price to pay.
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.
Good luck in your endeavours!
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?
It's not so simple:
- 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?
Sure:
- which business is behind the website?
- when was said business incorporated?
- how many employees does this business have?
- what is the jurisdiction and canonical registration identifier of this business?
All useful info for an agent determining how much to trust the content on a website and whether to transact with it
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?
Easier than ever. Should I really log in with my Microsoft credentials to auth.gfx.ms?
I don't understand this question, sorry.
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.
If 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.
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 unique 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.
> 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.
https://scotthelme.co.uk/are-ev-certificates-worth-the-paper... https://www.troyhunt.com/extended-validation-certificates-ar...
Question for HN regarding EV certs:
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?
anyone who has ever worked at a large non-technical company can tell you exactly where these requests came from
The green bar from HTTP EV certificates is being reincarnated as the green tick of email BIMI Verified Mark Certificates (VMCs)
Keeping identity separate from TLS makes a lot of sense to me!
Spooky!
[dead]
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!
Do you have any reason to believe that your interlocutor is in favor of the U.S. government enforcing regulations beyond its borders?
Yes. The entire internet is US-shaped. From social networks applying ridiculous puritan beliefs globally to the madness that is the TLD system, DMCA, the CLOUD act… all the way to the NSA spying on non-US citizens to protect themselves.
A Puerto-Rican crypto bro wouldn’t have a career without the USA exerting their will and regulations onto the rest of the world.
I think most American tech people are against most of those things? Why would they not have careers without them?
So: no, you do not in fact have any reason to believe that, and you are just assuming it without any evidence.