X.509 validation is nominally disjoint from domain names. [X.509][1] was designed in the context of **The Directory**, a mythical beast which can be thought of as a big, worldwide LDAP directory referencing every server on Earth and elsewhere. (Historically, it went the other way: LDAP is _Lightweight Directory Access Protocol_, a reduced version of the protocol which was meant to access the Directory.)

In the Directory, entities are designated by their _Distinguished Name_, a tree-like structure which has no relation with domain names (although some people have forced one into the other with "DC" DN components).

In true X.509, allowing a certificate owner, linked to a domain name, to act as a sub-CA for its own sub-domains is **theoretically possible**, but requires the use of the `Name Constraints` extension, which is [standard][2], but almost universally unsupported. The idea would be to issue a certificate containing the name `example.com`, marked as a CA (`Basic Constraints` extension with `cA` set to `TRUE`), and `Name Constraints` extension with a "permitted subtree" of value `.example.com` (this should constrain ulterior certificates to sport host names, and these names may only be in subdomains of `example.com`). It is a neat idea, but it fails due to lack of support from browsers. So the net effect, if a CA issues such an empowered certificate to a domain, will be one of the two followings:

 - Client browser rejects the certificate.
 - Client browser accepts the certificate, but would also have accepted it even if it was not a proper subdomain.

Browser vendors are not keen on implementing this feature because it would be quite useless until commercial CA use it, and commercial CA won't use it until it is implemented by browsers. Moreover, commercial CA tend to prefer it if you buy several certificates from them instead of just one.

To sum up, this is a sad story of X.500 people not getting along well with IP/DNS people, and browsers not implementing the necessary features to get the whole thing to work. Things are unlikely to change in the near future.


  [1]: http://en.wikipedia.org/wiki/X.509
  [2]: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10