If you're talking about limiting to certain TLDs, like American CAs not being able to issue .ca or .in or .paris, there is a spec for that, called name constraints. It is intermittently supported, and there was a thread on mozilla.dev.security.policy, primarily focusing on government CAs, which argued that doing such a thing fractures the open/egalitarian nature of the internet, by making zones where security is less important:

https://groups.google.com/d/topic/mozilla.dev.security.polic...

I can imagine other ways you would restrict certificates (for instance, I'd kinda like to see a spec for a "half-CA", where you need two half-CAs under distinct organizational control to sign you), but I don't think anyone has specified the problem for those precisely, let alone proposed a solution.

Yes using "Name Constraints" but that RFC / extension is really broken, and implementations don't support it. See 4.2.1.10 of https://tools.ietf.org/html/rfc5280.

That's how SPKI (RFCs 2692 & 2693) worked: one only trusted an authority for certain things. This would work very well for DNS names and IP addresses alike, since both are allocated hierarchically; with SPKI one could guarantee that one is talking to one of the parties who is allowed to use a name or an address.

Sadly, SPKI more-or-less died on the vine: the atrocious XPKI 'system' won by default. One of my rainy-day projects is to try to revive it: if the last 15 years have taught us anything, it's that centralised global trust is insane.

AFAIK, no it's not. However, this is the solution as far as I see it. When you buy a domain name from a registrar they should give you a mini-CA that's valid for just that domain for as long as the domain is registered. Then it's up to you to create and sign any certs for any subdomains. This would cut out the CA businesses entirely, enabled security-by-default, and simplify the whole system.