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 FALSE
.
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...