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

[Alan Sill <Alan.Sill@xxxxxxx>]

On Oct 13, 2005, at 5:29 AM, David Chadwick wrote:

> Frank Siebenlist wrote:
>
> > I don't care about the collisions - that's a non-issue as far as  
> > I'm concerned.
> > [...]
> > 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.
>
> 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.
I have to agree with David here.  The issuance of the certificate is  
an authentication issue, not an authorization one.   The CA asserts  
that it has verified teh identity of the person to whom it has issued  
the cert, and in principle there is no problem at all with more than  
one CA verifying the personal identity of an individual to whom it  
issued a cert.  So it is not a matter of impersonation -- if one of  
your other trusted CAs verifies the identity of your director and  
issues him or her a certificate, this is redundant.  If that CA does  
so maliciously or in error, it has violated the conditions for being  
a trusted CA and should be dropped.  That's what CA trust is about.

As for the issue of naming constraints, I see two issues: a technical  
one, and a practical / best practices one.  If we agree to the above,  
then the technical issue appears to boil down to whether openssl  
0.9.8 is common enough to allow naming constraints to be used to flag  
potential problems: "hey, I happen to notice that this cert does not  
conform to x and so expected pattern" -- then the next step would be  
either to (a) downrate the capabilities of the user based on that  
information, or (b) simply print an informational flag.

Are there any other issues?

Alan Sill
TIGRE Senior Scientist
High Performance Computing Center
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: Alan.Sill@ttu.edu   ph. 806-742-4350  fax 806-742-4358  :
====================================================================