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

[David Chadwick]

Mike

this shows what a crap service Thawte are offering. Basically they will 
link any name to any public key, so the binding is worthless. YOu might 
as well issue your own self signed certificate.

As to your assertion that you have the same name on all your cards, well 
I would expect this, since all the cards belong to the same person.

Also I dont have a problem with two CAs issuing me with certs containing 
the same DN, in fact I would want them to. What I have an issue with is 
a CA issuing my name in someone else's cert. This shows that the CA is 
not authenticating the right to use the name.

BTW, the use of an email address is a perfectly good globally unique DN, 
and its pretty easy to prove ownership of it. This is how Verisign issue 
their certs. They send a secret to the mail box of the user.

regards

David


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.
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************