Name Constraints, was Re: [caops-wg] Re: ca signing policy file
Alan.Sill at ttu.edu
Thu Oct 13 08:49:06 CDT 2005
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
>> 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?
TIGRE Senior Scientist
High Performance Computing Center
: Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 :
: e-mail: Alan.Sill at ttu.edu ph. 806-742-4350 fax 806-742-4358 :
More information about the caops-wg