David Groep wrote:
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?
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. To explain more fully, the X.509 name constraints had the original intention of limiting which certificates issued by a subordinate CA could be trusted. Those that fell outside the constrained name space were not to be trusted. RFC3280 perverted this, by adding a sentence that stated, if the subordinate CA issued a cert with a name form that was not in the name constraints extension, then this cert should be trusted. This now blows a hole in the trust assumptions of the superior CA, since a subordinate CA can now legally circumvent the name constraints by issuing certificates using a different name form. The current debate in the X.509 group is whether to revert to the original semantics or keep the perverted 3280 ones. I think this mainly boils down to the fact
that while they look suitable, they are intended for bridging situations and we'll never get commercial CAs to adopt them,
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. Now if you are telling me that most commercial CAs do not support name constraints, that would be a powerful argument to support reverting name constraints back to their original semantics. Can anyone give me evidence of support or non-support of commercial CAs for the name constraints extension? hence
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.
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.
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 :-)
What does bronze CA mean in the context of name constraints. Bronze, silver, gold etc do not sound like a naming constraint to me, but rather a CPS or policy issue
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.
I think currently it has to be outside the standard certificate path validation algorithm, due to the bug introduced by 3280, which will let certificates not in the constrained domain slip through the net as being valid, as explained above. regards David ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************