"MITM certificates" are those used for the purpose of intercepting secure traffic. Many organisations have the certificates to do that, but are under audits, and technical and legal constraints not to.

That's very different from, say, TrustWave, who issued such a certificate with full knowledge of what it would be used for.

I agree that this isn't the best of situations. Certificate Transparency is the best answer that we have, but it's going to take a while to deploy.

I think it would be more accurate to say a "MITM certificate" is any private key with the ability to impersonate server and intercept SSL/TLS traffic.

There's a huge difference in security between a cryptographic-strength guarantee enforced by reliable technical mechanisms and the security provided by a civil law contract enforced by an audit regime. Also, note that the world's true Relying Parties (i.e., every web user and server operator who could potentially be MITM'd by this private key) are usually not formally acknowledged as parties to these contracts and as such have no say in their creation or even knowledge of their existence.

It's a question of terminology, but when groups like Chrome Security, Mozilla etc talk about MITM certificates and that they are forbidden, we mean those that are used for intercepting traffic.

I think this is a case where the precise terminology is critical.

The only way to know how a certificate may or may not "be used" is by looking at how the source code of all client applications to see how they will interpret it.

How many of the cases of trusted-root chained MITM seen in the wild (Iran, Turkey) were prevented by the business agreements making MITM "forbidden"?

But - is there anything inside these certificates that identify to a browser what the "intended purpose" of a given certificate is, and prevents such a CA from being used for MITM attacks? How would a regular browser such as IE or Safari act when presented with a certificate for "bank.example.com" signed by such a CA?

Yes: the X.509 nameConstraints field, which modern browsers will read to determine which subdomains are acceptable as subjects for certs signed by the CA.

Earlier today I thought that nameConstraints was ineffective, but it seems to turn out that the problem is mostly limited to Safari.

Hm ok, I guess that makes it less of a big deal, but it still sits funny with me.

I guess all iOS devices are still "vulnerable" to a rogue nameConstrained CA then - assuming they share code with Safari?