They aren't MITM certificates, they are cross-signs for enterprise deployments. If you run a large enterprise you might have lots of foo.corp.example.com and bar.corp.example.com hosts. A cross-sign would allow you to issue certs for these names that would be trusted by default.
It may also give you the power to issue certificates for any name or, hopefully, it will be name constrained([1]). That's up to the CA however. The CA is taking on responsibility for all certificates issued under these cross-signs when they do this. Mozilla is currently in the process of requiring that these enterprise certificates either be name constrained, or be audited at the same level as roots.
"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.
For us we require CAs that are not technically constrained to be independently audited to WebTrust for CA requirements, Moving forward thanks to Mozillas new policy the same will be true for all CAs.
Thanks for the clarification. On a related note do you understand where the X.509 Name Constraints effort sits? Which, if any, browsers implement it? If it's not 100%, do you know why browsers are hesitant to deploy it?
Name Constraints support is pretty good in modern certificate libraries. It's certainly in CryptoAPI these days which accounts for the bulk of users.
But there are two ways to use Name Constraints: they can be marked critical or non-critical.
Critical Name Constraints are great, but they will cause anything that doesn't support Name Constraints to reject the certificate. This is obviously a problem because few deployments have much control over their client base.
Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.
I'm not sure, but in the back of my mind I don't think that it does. I've agreed to write about this stuff for the Web PKI Working Group so I'll need to do a survey of the various capabilities at some point.
It may also give you the power to issue certificates for any name or, hopefully, it will be name constrained([1]). That's up to the CA however. The CA is taking on responsibility for all certificates issued under these cross-signs when they do this. Mozilla is currently in the process of requiring that these enterprise certificates either be name constrained, or be audited at the same level as roots.
I think Symantec will sell you much the same thing: http://www.trustico.com/material/DS_GeoRoot_0205.pdf
This is one of the reasons that we are pushing Certificate Transparency: http://www.imperialviolet.org/2012/11/06/certtrans.html
[1] X.509 Name Constraints allow an intermediate or root, CA certificate to be limited to issuing certificates within a certain scope, i.e. a domain. https://tools.ietf.org/html/rfc5280#section-4.2.1.10