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

David Chadwick d.w.chadwick at kent.ac.uk
Thu Oct 13 04:26:21 CDT 2005



Frank Siebenlist wrote:
> Sorry, but I have to disagree strongly.
> 
> Having no name constraints and letting any CA issue any name it wants, 
> puts all your trusted CAs on equal footing concerning the names they 
> issue: any CA can overstep its policy boundaries concerning the issued 
> names and you have no way to find out.


Frank

if the names are completely unique random numbers (such as a hash of a 
public key), then I dont see your problem with a CA overstepping the 
boundaries. Can you be more specific about what the problem is.

A CA is a certification authority, not a naming authority. The purpose 
of a CA is to bind a name to the public key. The CA should not be 
responsible for allocating the name, only authenticating that the user 
has the right to use the globally unique name it claims. If the name is 
a hash of the public key, then anyone can claim this right through POP. 
If the name is based on a passport of SS number or email address then 
the CA can authenticate this. In this type of scenario name constraints 
are not that useful. They can be introduced if you want to say things 
like only the US CA can issue certs based on US passport numbers. One of 
the ways that PKIX went wrong was by giving the CA the naming authority 
role as well as the certification role, because it reduced the liability 
of the CA (it did not have to do a full job anymore).

regards

David

> 
> Some form of enforced name constraining policy or localizing the 
> name-issuing to a CA is the only safeguard you have against any rogue CA 
> among the zillions that may be present in your trusted CA-directory.
> 
> Wasn't that the main reason that we have our current ca signing policy 
> files in the first place?
> Did I miss anything?
> 
> -Frank.
> 
> 
> Mike Helm wrote:
> 
>> "Cowles, Robert D." writes:
>>  
>>
>>> that the middleware includes a check of the CA when it compares
>>> on DN, then what you say is correct.
>>>     
>>
>>
>> This is one of the essential problems with this service that
>> has never been addressed as far as I know.  name constraints
>> "be" an incomplete barrier.
>>
>> BTW, we have found this omission _useful_ in our past.
>>
>> We switched from a test, development lab CA (DOE Science Grid) to a 
>> production
>> quality CA (doegrids), and we used this property to ease subscribers'
>> transition to the new CA.  Lesson?  Overlapping name spaces
>> might be useful!
>>
>>   
> 
> 

-- 

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

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





More information about the caops-wg mailing list