[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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@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@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory