Fraudulent *.google.com certificate issued

For spoofing foobix.com, you need fake keys for the root, for com. and for foobix.com. But you don't need fake keys for any domain you're not interested in, as you just sign the anchors for the legitimate keys with your key. And this signing can be done inline, at speed.

CAs can constrain themselves with nameConstraints; more commonly, a trusted CA would charge $$$ for a corporation to be able to issue their own certs without needing to go up, because the corp has scaling issues getting their own root cert onto every client device in a trusted manner, across all the vendors and contractors and the like; so example.com megacorp pays $$$ to the root CA for a basicConstraints CA:TRUE cert and the root CA preserve their income stream by making sure the newly minted CA cert has nameConstraints=permitted;DNS:*.example.com in it.

Another reason to be worried when software doesn't do any certificate chain validation, or tries to roll its own validation steps for the chain.

What's needed is constraints _outside_ the CA's control. A nameConstraints which can be applied to the CA, to keep the certs in-country and optionally warn for use outside the country, for vetting/approval (but default to block, to avoid continuing to train people to click through stuff they don't understand). What's needed is more of the steps like Google's cert-pinning, letting site operators at least get as far as the SSH security model of "latch on first use". Not ideal, but a massively reduced attack window (which can be shrunk to zero if you get the pinning into the source, rather than learnt; that then leaves "just" compromise of the browser distribution mechanism ...)

See:
http://scarybeastsecurity.blogspot.com/2011/04/fiddling-w...