I recognize that they had a lot of issues and I'm glad the implementation of EV certs that we <i>had</i> 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.<p>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...)<p>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.<p>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?<p>ccTLD name constraints are an old idea, back in the news again lately for obvious reasons, and the same arguments against them still apply: <a href="https://groups.google.com/g/mozilla.dev.security.policy/c/pF4aVsF21ww/m/31qQd3i0ulIJ" rel="nofollow">https://groups.google.com/g/mozilla.dev.security.policy/c/pF...</a><p>Are there other use cases besides those that you think the Web PKI should support?
> the same arguments against them still apply<p>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:<p>> 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.<p>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 <i>prefer</i> 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.<p>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.)<p>> any particular reason to think that the Stripe problem is solvable<p>I'd imagine, in a "proper implementation":<p>- 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.<p>- 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.<p>- 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 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.<p>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.<p>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.<p>I can't express how great it is that EV certs died.
The browser vendors, I think, were at least making a good-faith attempt to address a real security problem; it's not like <i>they</i> 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).<p>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.<p>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.<p>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.<p>After the BRs go into force in July 2012 that's against the rules. It doesn't stop <i>happening</i> immediately, but it is now clearly forbidden, so at least they say "Sorry, won't happen again" and cross fingers they actually mean it.<p>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 <i>10 year</i> 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?<p>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.<p>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.<p>This is a success story, and EV certs were a very small price to pay.
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.<p>If anyone is interested:<p><a href="https://github.com/mieko/greenbar" rel="nofollow">https://github.com/mieko/greenbar</a><p>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.<p>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.
Clarification: Browsers or other user-agents are not required to trust QWACs for use in TLS. We fought very hard for this.<p>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.<p>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!<p>Though I don't understand why they would atone for any sins. IMHO, you created the website identity infrastructure for the agentic web...<p>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.<p>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.<p>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.<p>Good luck in your endeavours!
Very interesting history, thank you for sharing. I had wondered about the design choices there.<p>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.<p>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.<p>But for an agent that knows to look out for these signals, extensible 2-QWACs will be extremely valuable.
<i>> 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.”</i><p>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.
Question for HN regarding EV certs:<p>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.<p>Is there any point in doing this?<p>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.<p>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.<p>Can anyone think of a legitimate technical motivation to use EV certs alongside an overlapping Wildcard OV and various DVs?
<a href="https://scotthelme.co.uk/are-ev-certificates-worth-the-paper-theyre-written-on/" rel="nofollow">https://scotthelme.co.uk/are-ev-certificates-worth-the-paper...</a> <a href="https://www.troyhunt.com/extended-validation-certificates-are-dead/" rel="nofollow">https://www.troyhunt.com/extended-validation-certificates-ar...</a>
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!
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).