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

[Frank Siebenlist]

David Chadwick wrote:
> ...
>> I don't care about the collisions - that's a non-issue as far as I'm 
>> concerned.
>>
>> The only sticky point I see, is the ability for any of your trusted 
>> CAs to issue certificates outside of their administrative domain and 
>> only to rely on essentially paper agreements to prevent this.
>>
>> Note that with Kerberos cross-realm authentication, one realm is 
>> unable to issue credentials for the director of the other institute...
>>
>> With your proposed scheme, any "trusted" CA in Italy, Germany, even 
>> Holland..., would have the theoretical opportunity to issue a 
>> certificate that would impersonate the director of Berkeley, NCSA, 
>> Livermore, Los Alamos... and we would have no way to enforce any 
>> policy in real-time that could prevent it.
>
> Using names based on hashes of public keys, the only way I could 
> impersonate the director would be to get hold of his private key. And 
> then it does not matter which CA issued his cert with whatever name it 
> put there. Once I have the private key, I AM the director.

Hmmm, that idea sounds vaguely familiar ;-)

This would indeed prevent anyone from impersonating the director, but 
again relies on a custom enforcement of that policy, i.e. custom path 
validation code - in a way this can be seen as a form of an imposed name 
constraint.


> So, if the name is allocated properly, this is not a real risk. It all 
> comes back to the same issue I mentioned before, that the CA has to 
> prove that the person has the right to assert the name that it is doing.
>

No arguments there.

-Frank.


>> If this acceptable to all our end user organizations, we should 
>> happily adopt the web-browser trust model with paper CA policy 
>> statements... and I'm serious here.
>>
>> So what are the real "trust-requirements" we are working from?
>>
>> Regards, Frank.
>>
>>
>> Mike Helm wrote:
>>
>>> Frank Siebenlist writes:
>>>  
>>>
>>>> In other words, the Subject's DN should start with an identifier 
>>>> that essentially identifies the administrative domain in which the 
>>>> names are issued, e.g. \DOMAIN=ESNET.NET, followed by a 
>>>> \CN=abbf16d0-3b5f-11da-8cd6-0800200c9a66
>>>> In that way, a CA could be restraint to issue random names within a 
>>>> certain domain.
>>>>     
>>>
>>>
>>> Here's the subject name I had from Thawte:
>>> E = helm at fionn.es.net, CN = Michael Helm
>>>
>>> That's it.
>>>
>>> The E= was just for my convenience.  I could create other certificates
>>> with a different E= attribute if I needed to.
>>>
>>> Name collisions by themselves - so what?  I have the same
>>> name on my driver's license and on my library card.  Nobody
>>> gets worked up over that.  What I think you want, is
>>> to make sure that same name string isn't certified to
>>> two different people.  But we don't have technical means
>>> guarantee this. Even the current name constraints / signing policy
>>> scheme cannot prevent this, it can only make it a little more
>>> difficult.
>>>
>>> You can eliminate most "legitimate" collisions by including
>>> some link to the issuer in any authentication determination.
>>> That's the administrative domain.
>>>
>>> You find some CA issues duplicate DN's from other domains?
>>> Don't use them.   In any event, having an issuer field will limit 
>>> what damage they can do.
>>>
>>> You find some collision?   You don't like it?  Take it up with the 
>>> CA's that
>>> did it.  They are highly motivated not to have this problem.
>>>
>>> Why is this such a huge problem?  I have never understood the amount 
>>> of time & energy spent on it in our community.  I sure wish we 
>>> didn't have
>>> the current signing policy file scheme.
>>>
>>>   
>>
>>
>

-- 
Frank Siebenlist               franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory