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

[Mike Helm]

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.