David Groep wrote:
No, this would be unfortunate. The RFC 3280 Name Constraints semantics have perverted the original X.509 semantics so that a superior CA can no longer use name constraints to constrain all name spaces issued by the subordinate CA. We currently have a defect report on this issue being actively discussed in the ITU-T X.509 standards group.I actually agree (it's just the habit that crept in here). I also think that the "namespace constraints policy collection (file)" should just be "namespace constraints file" or something similar.I think one question the document should address is why not use RFC 3280 Name Constraints?
actually I am being told by the RFC3280 lobby that commercial CAs do support name constraints, and because of this we cannot revert their semantics back from the RFC3280 meaning to that of the X.509 original meaning, because it would break their implementations.that while they look suitable, they are intended for bridging situations and we'll never get commercial CAs to adopt them,
It is actually meant to be the superior authority that places the constraints on the subordinate CAs. CAs themselves can issue certs with whatever subject names they want to. They can also constrain themselves or not. So if a CA were to constrain itself, it would be through its CPS or CP. The name constraints extension is to constrain subordinate CAs.always limiting ourselves to "Grid CAs". If everyone agrees with that statement, I'll plan on contributing some prose.
I've a few other reasons to add to this as well: For nameConstraints in the certificate itself is that it's the "wrong" authority makiong the assertion. For these namespace policies, it's not the CA itself but rather the distributor or federation that makes the claim.
The example again is SwissSign. In the federation, their (top-level) CA is limited to signing only the "Bronze" CA. This constraint is coded in the namespace constraints file. But of course, they'll never but in a nameConstraints assertion in their top-level limiting it to Bronze only :-)
Also, only a subset of the certificates issued by a CA may be part of the federation, and limiting the namespace is a relatively straightforward way of doing that (instead of having to introduce a subordinate CA for that). In all cases, the namespace constraints should be outside of the certificate chain of the constraint CA.