Name Constraints, was Re: [caops-wg] Re: ca signing policy file

[David Chadwick]

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

*****************************************************************