Who killed the EV cert? A browser whodunit for Halloween

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.

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)

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.

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!