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