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?

▲

ipdashc 33 minutes ago | parent [-]

> 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.

▲

rlpb 16 minutes ago | parent [-]

> 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.

	▲	wongarsu 4 minutes ago \| parent [-]
		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