Also, other people in this thread have commented that the 4.2.1.10 name constrained thing isn't really implemented anywhere?
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.
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.
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"?
Earlier today I thought that nameConstraints was ineffective, but it seems to turn out that the problem is mostly limited to Safari.
I guess all iOS devices are still "vulnerable" to a rogue nameConstrained CA then - assuming they share code with Safari?
They are used by large environments like Google and Microsoft to issue certificates for their assets and people.
They are contractually and technically (new but now standard) prohibited from using them for malicious use cases including MiTMs.
They are audited to conform with those terms and must meet the same requirements a certificate authority in the Mozilla guidelines.
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.
Here is a summary of where clients were a year ago, opera has support now so its slightly out of date - http://unmitigatedrisk.com/?p=24
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