Eve could sign a certificate stating "a.com" as name, with her private key, but Bob's browser will not accept it. When Bob's browser validates a certificate chain, it verifies all signatures, but not only the signature. The complete validation algorithm is intricate; see the standard. In this case, Bob's browser will raise a metaphorical eyebrow when applying check (k) from section 6.1.4: Eve's certificate is a "version 3" certificate, but does not contain a
Basic Constraints extension, or its
Basic Constraints extension has the
cA flag set to
In short words, though certification is a kind of power delegation, the power to issue certificates is specified to require explicit delegation, and is not done by default. As @Terry says, commercial CA can grant sub-CA certificates, with the
cA flag set to
TRUE, but they will charge a lot for that. In fact, they will contractually bind the sub-CA to honour the Certification Practice Statement of the CA (see there for the CPS of Verisign). The contractual obligations include a lot of big money talks with insurances and things like that, so that a sub-CA Eve who would issue fake certificates would be blasted into oblivion by the legal retaliation from Verisign. They make no prisoner.
Things used not to work that way in the past. The first version of X.509 did not support extensions, so clients had to find some other way to verify whether a given entity had the CA power or not. This was inconvenient, because browsers had to choose between embedding a growing list of "allowed sub-CA", or simply trust all certificates with CA power (thus allowing your attack). Note that up to year 2003 or so, there was a bug in Internet Explorer: IE did not check the
Basic Constraints extension at all ! When this was discovered, it was promptly patched, of course...