It is possible to create a root CA that cannot be used for SSL by... not using it for SSL !
When a CA issues a certificate for a sub-CA, it does so within the context of a given trust contract. The sub-CA agrees to issues certificates only in accordance to a number of rules which are made explicit in the Certification Policy and the Certificate Practice Statement -- these are legal documents meant for human consumption. If you want a root CA which can be used for S/MIME but not for SSL, then the root CA must state in its CP and CPS that certificates which relate to this root CA must not be used for SSL. In particular, sub-CA take the formal oath never to issue SSL-able certificates (i.e. they won't put machine names in Subject Alt Name extension or in the Common Name part of the SubjectDN; and they will put a critical Extended Key Usage extension which says "for S/MIME only").
In X.509, there are two categories of such "PKI rules":
Rules which are enforced by the validation algorithm. Name Constraints, for instance, can (theoretically) be used to prevent validation of certificates such that the end-entity certificate's name is not part of a namespace of allowed names duly specified in one of the intermediate CA certificates.
Rules which are not enforced by the validation algorithm. The "no SSL" rule would be such a rule.
In pure X.509 theory, there is no actual need for rule enforcement in the validation algorithm; revocation is used to maintain order and punish misbehaving entities. However, in practice, revocation is asynchronous, and too slow to react to "flash attacks". An attacker who wants to run a fake server only needs ten minutes or so to enact considerable mischief; seeing his certificate revoked two days later won't deter him. This is why a number of PKI rules are now enforced at the validation level, first of which being incarnated by the Basic Constraints extension: a certificate owner is not granted CA power.
There is (currently) no such automatic enforcement of rules pertaining to Extended Key Usage. If a CA wants to enforce a no-SSL rule, then it must not issue certificates which can be used for SSL, and it must make sub-CA swear to comply to the same rule. Lack of such enforcement is a problem only if a sub-CA misbehaves, and the obtained certificate can be used as a SSL server certificate to perpetrate some odious crime before righteous revocation smites the offending sub-CA.
(Note that the Key Usage extension only covers a handful of generic use cases, such as "encryption" or "signature", and this is unrelated to Extended Key Usage. Moreover, the Key Usage extension is no more inherited along a certificate path than the Extended Key Usage extension.)
There is another point where rules can be engraved: in the clients. Clients trust root CA (that's what makes them "root CA"), but they can trust them for specific roles only. See for instance this screenshot from the certificate viewer in Firefox's preferences:
The list of "uses" is configurable and allows the client to restrict a given CA to some specific situations.
- is not backed by information written in the root CA certificate itself, but by metadata which must be maintained by some out-of-band mechanism;
- is not standardized (every system has its own notion of "roles");
- is specific to root CA (trust anchors) and cannot be attached to an intermediate CA;
- is worth anything only insofar as the relevant applications mind the restrictions and enforce them.
Yet it works. If you want an S/MIME-only root CA, then distribute it and have it installed in clients with the tag "for S/MIME only". This is as good as a full-path automatic EKU extension (if such a thing existed).