I'm not 100% sure, but fairly certain the way that x.509 works, there is a boolean field for whether or not the certificate is an authority, with no control over what they are an authority for. I believe this field is called basic constraints.
There is something called "name constraints" in X.509 that can be used to control which domain names, email addresses, etc. a sub-CA certificate can issue certificates for. See [1]. CAs are using them more and more frequently, especially after Mozilla added items #9 and #10 [2] to its inclusion policy a couple years ago.
In Mozilla's implementation, name constraints are applied to the CN field. I believe Chrome is the same way. Also, browsers "validate domain names" against the CN attribute and the dNSName entries in the subjectAltName extension.
Source: I wrote all that code in Mozilla's implementation.
Have you reasons to believe the existing x509 certificates handling code handles properly an extension that is seldom used, and will do it in all cases?
Validation of x509 certificates is ridiculously complex, and CA rightfully only use the widely interoperable subset of extensions...
Then you're likely in the top 10 experts of the field ;)
The fact that OpenSSL did it wrong for 15 years doesn't bode well for the myriads of TLS implementations that are around.
My experience with the x509 part of SSL/TLS stacks is really not good when you start to use something else than OpenSSL/NSS (well PolarSSL is pretty good too). Quite often there is enough implemented to interoperate in the common use cases, but you're on your own if you need a complete standard support... Then it has been a while, maybe it's a lot better now.
