October 2005 - caops-wg - lists.ogf.org

RE: Name Constraints, was Re: [caops-wg] Re: ca signing policy file
by Cowles, Robert D. 14 Oct '05

14 Oct '05

The name constraints are important because the gridmapfile doesn't contain the CA that issued the DN, only the DN. Therefore, name collisions can occur and cannot be detected. If we make sure that the middleware includes a check of the CA when it compares on DN, then what you say is correct. > -----Original Message----- > From: owner-caops-wg(a)ggf.org [mailto:owner-caops-wg@ggf.org] > On Behalf Of David Chadwick > Sent: Wednesday, October 12, 2005 10:57 AM > To: helm(a)fionn.es.net > Cc: Von Welch; Tony J. Genovese; 'Frank Siebenlist'; > 'CAOPS-WG'; 'Olle Mulmo'; 'Joni Hahkala'; 'Jules Wolfrat'; > 'Ron Trompert' > Subject: Re: Name Constraints, was Re: [caops-wg] Re: ca > signing policy file > > Mike > > this is a very interesting viewpoint. What you are saying, if > I put it > another way, is that everyone can have a completely random name, its > irrelevant what it actually is, as long as the user can > authenticate to > that name (via signing something whose signature validates with the > certificate containing that name) and then as long as the > authorisation > infrastructure can reliably get the set of attributes that > are bound to > the same name, then correct authorisation can be performed, > regardless > of the name of the user. In which case name constraints are > irrelevant. > I would agree with that > > regards > > David > > Mike Helm wrote: > > Von Welch writes: > > > >>I meant to say that unless NameConstraints are adopted by CAs in > >>general (which probably means both "Grid CAs" as well as all the > >>various software packages our communities use to generate > >>certificates), we still need something like current ca signing > >>policies (i.e. relying party-specified name constraints). > > > > > > I don't think name constraints, in general, no matter who does them, > > are worth the slitest amount of our attention. They don't solve > > any problem that anyone actually has. (I think this is one reason > > rfc 2459 name constraints took so long to get any support.) > > > > This is particularly true in grid environments where the > authentication > > and authorization has been separated. > > > > What we do need, just like in any other pki, is some way of stating > > whether or not a CA is trusted, and for what purposes (cert types). > > If "purposes" includes naming, fine, but I don't think that > > should be its primary or only method. One purpose might > > be "any" or "none": A scheme like that would > > be very useful to the middleware: you can distribute a large > > number of CA signing certs and make it easy for the > > relying party to configure the CA trust list. (Most of our > > current CAs are grid-only.) > > > > The current signing policy file is useful, in that it puts a brake > > on what is going to be trusted, but the only decision it allows > > is based on naming, which I contend is useless, and forces people > > to deal with an inherently clumsy syntax that has been > dis-optimized. > > > > A side effect is that it places a huge emphasis on naming in Grids, > > which is a waste of everyone's time. We should be free to use > > whatever naming is appropriate and not jam ourselves into narrow > > naming rules so that we don't disturb the delicate naming policy > > rule distributed everywhere. Since names in grids have no inherent > > meaning and we have authorization schemes to enroll and control > > privileges on successful authentication, the name > constraint in Grids > > doesn't add anything. I also think this is functioning as a > > market inhibitor, in that CAs that don't fit this pattern such > > as commercial CAs or other schemes are kept out of the business. > > > > > > -- > > ***************************************************************** > 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(a)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 > > ***************************************************************** > >

6 21

RE: Name Constraints, was Re: [caops-wg] Re: ca signing policy file
by Cowles, Robert D. 14 Oct '05

14 Oct '05

The gridmapfile gives no clue as to CA or to VO. Why do PKI *users* care about 2)? Unless you consider the CA's to be "PKI users*. BC > Bob > > I think 2) is the main reason used by PKI users in general. > What are the design flaws in 1)? > > thanks > > David > > > Cowles, Robert D. wrote: > > My impression of why we had the constraints were: > > > > (1) gridmapfile design flaw > > > > (2) the CA's wanted some limitations so as to help > > divide up the people coming to them ... so that > > one CA didn't have to issue certs for the whole > > world (since it's being done on pretty limited > > budgets). > > > > BC > > > > > >>-----Original Message----- > >>From: Frank Siebenlist [mailto:franks@mcs.anl.gov] > >>Sent: Wednesday, October 12, 2005 12:09 PM > >>To: helm(a)fionn.es.net > >>Cc: Cowles, Robert D.; David Chadwick; Von Welch; Tony J. > >>Genovese; CAOPS-WG; Olle Mulmo; Joni Hahkala; Jules Wolfrat; > >>Ron Trompert > >>Subject: Re: Name Constraints, was Re: [caops-wg] Re: ca > >>signing policy file > >> > >>Sorry, but I have to disagree strongly. > >> > >>Having no name constraints and letting any CA issue any name > >>it wants, > >>puts all your trusted CAs on equal footing concerning the > names they > >>issue: any CA can overstep its policy boundaries concerning > >>the issued > >>names and you have no way to find out. > >> > >>Some form of enforced name constraining policy or localizing the > >>name-issuing to a CA is the only safeguard you have against > >>any rogue CA > >>among the zillions that may be present in your trusted CA-directory. > >> > >>Wasn't that the main reason that we have our current ca > >>signing policy > >>files in the first place? > >>Did I miss anything? > >> > >>-Frank. > >> > >> > >>Mike Helm wrote: > >> > >>>"Cowles, Robert D." writes: > >>> > >>> > >>>>that the middleware includes a check of the CA when it compares > >>>>on DN, then what you say is correct. > >>>> > >>> > >>>This is one of the essential problems with this service that > >>>has never been addressed as far as I know. name constraints > >>>"be" an incomplete barrier. > >>> > >>>BTW, we have found this omission _useful_ in our past. > >>> > >>>We switched from a test, development lab CA (DOE Science > >> > >>Grid) to a production > >> > >>>quality CA (doegrids), and we used this property to ease > >> > >>subscribers' > >> > >>>transition to the new CA. Lesson? Overlapping name spaces > >>>might be useful! > >>> > >>> > >> > >>-- > >>Frank Siebenlist franks(a)mcs.anl.gov > >>The Globus Alliance - Argonne National Laboratory > >> > >> > > > > > > -- > > ***************************************************************** > 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(a)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 > > ***************************************************************** >

2 2

RE: [caops-wg] Name Constraints - attempt at framing issues
by Cowles, Robert D. 14 Oct '05

14 Oct '05

> Trusted third parties that cannot be trusted!! Why are we > bothering with > them? Building a whole trust infrastructure on untrusted TTPs is a > pointless exercise in futility. > Yes ... well, it was pointed out at the last EUgridPMA meeting that the VO's go thru almost the exact same process to register people ... so what value did the CA's provide? BC

3 2

RE: [caops-wg] Name Constraints - attempt at framing issues
by Cowles, Robert D. 14 Oct '05

14 Oct '05

> 1) What CAs do we wish to consider as potential issuers for our > community? Is it just "Grid CAs" (by that I mean CA we can > reasonably > except to adhere to best practices as specified by GGF WGs) or do we > want to also consider CAs that we have no reasonable expectation of > being able to impact their policies or procedures (e.g. commercial > CAs) as potential issuers for our community as well? I think that if we are successful, all this will be used in ways we can't now imagine or, in the future, control. To me, the idea of depending on CA's to issue certificates for DNs that are globally unique is just asking for trouble. Administrative controls to keep the namespaces separate are clearly not good enough. The signing policy file is a technical control but it still seems pretty weak. To me, the thing that is unique is (DN + CA) and the function of the CA is to try it's best to not issue a cert with the same DN to different people. I would be happy if they can do just that and I think it unreasonable to believe that the DN is unique in the universe (or even a small section thereof). The signing policy files basically allow us to say - given this DN, it should have been issued by that CA - and as far as I can see, it's because the CA is't stored in the gridmapfile (and maybe it's not there because the DN was suppoed to be unique - but that was8-10 years ago, and we know better now). > > 2) Do we believe that during normal operation the CAs indicated in > the response to the first question have policy that will result in > their issuing globally unique names and will reliably follow that > policy? I think it's not true in "normal operation" and that any moderately talented attacker would be able to generate a condition outside of "normal operations" and get *someone* to issue a certificate with any DN they chose. > > 3) If a CA is compromised, given currently implementations, > this will (my comments here were in an earlier email).

4 4

RE: [caops-wg] Name Constraints - attempt at framing issues
by Cowles, Robert D. 14 Oct '05

14 Oct '05

No ... we already have a "sort of" structure for that ... it's called DNS. > > Bob > > dont you think it is a little optimistic to assume that a TTP that > cannot be trusted to issue unique names to its clients, can > be trusted to get a unique name for itself? > > regards > > David

2 1

RE: [caops-wg] Name Constraints - attempt at framing issues
by Cowles, Robert D. 14 Oct '05

14 Oct '05

There are lots of people named David ... should they all be the same person? Maybe they *should*, but that doesn't make it so. As a relying party, without a MUST and a reasonable way to implement it with good controls, I won't count on it. I'm a bit leery that the CA can ever perform the simpler job, but I can mitigate that risk by making the users register and if they want to use a new certificate they have to register the new one and say it replaces or is to be used as a synonym the old one .... not that I *automatically* the two certificates belong to the same EE. BC > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] > Sent: Friday, October 14, 2005 7:22 AM > To: Cowles, Robert D. > Cc: Von Welch; CAOPS-WG > Subject: Re: [caops-wg] Name Constraints - attempt at framing issues > > > > Cowles, Robert D. wrote: > > > > > I really have trouble believing that anyone would believe > > that brett or even brett(a)isp.net if identified by a certificate > > from CA1 would have any relationship to the same name appearing > > in acertificate from CA2. > > Dear Bob > > I am one of those who think they should refer to the same entity. > > David > > (In the case of the "email-like" address > > it depends on (1) the security of the email system ... for instance > > mindspring doesn't have a secure IMAP or POP option so I've just > > been sitting thru a conference where a few people's passwords are > > broadcast on the wireless network in clear text every 10-15 minutes > > ... (2) the policy of the isp about reuse of ids ... if the user > > with the email name brett leaves, can I have that id now? > > > > Bob > > > > > > -- > > ***************************************************************** > 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(a)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 > > ***************************************************************** >

2 1

RE: [caops-wg] Name Constraints - attempt at framing issues
by Cowles, Robert D. 14 Oct '05

14 Oct '05

> If CA1's key is also used to forge a certificate for Brett (even > though this is outside what CA1 such be signing). Are we concerned > about the additional threat that the forged Brett certificate could > also be used by the entity that compromised CA1 to further > compromise > the relying party? > > Thanks very much for the description. I really have trouble believing that anyone would believe that brett or even brett(a)isp.net if identified by a certificate from CA1 would have any relationship to the same name appearing in acertificate from CA2. (In the case of the "email-like" address it depends on (1) the security of the email system ... for instance mindspring doesn't have a secure IMAP or POP option so I've just been sitting thru a conference where a few people's passwords are broadcast on the wireless network in clear text every 10-15 minutes ... (2) the policy of the isp about reuse of ids ... if the user with the email name brett leaves, can I have that id now? Bob

2 1

Name Constraints - attempt at framing issues
by Von Welch 14 Oct '05

14 Oct '05

After reading through this long, interesting conversation, I would like to suggest the following questions to frame this discussion. Von 1) What CAs do we wish to consider as potential issuers for our community? Is it just "Grid CAs" (by that I mean CA we can reasonably except to adhere to best practices as specified by GGF WGs) or do we want to also consider CAs that we have no reasonable expectation of being able to impact their policies or procedures (e.g. commercial CAs) as potential issuers for our community as well? 2) Do we believe that during normal operation the CAs indicated in the response to the first question have policy that will result in their issuing globally unique names and will reliably follow that policy? 3) If a CA is compromised, given currently implementations, this will result in the compromise of all certificates issued by that CA. An additional threat that a CA compromise would result in, is the compromise of privileges bound to certificates issued by other CAs, at relying parties that trust the compromised CA. Is this threat of concern to us?

3 3

RE: [caops-wg] Name Constraints - attempt at framing issues
by Cowles, Robert D. 14 Oct '05

14 Oct '05

> 3) If a CA is compromised, given currently implementations, > this will > result in the compromise of all certificates issued by that CA. An > additional threat that a CA compromise would result in, is the > compromise of privileges bound to certificates issued by other CAs, > at relying parties that trust the compromised CA. Is this threat of > concern to us? > > Von -- can you describe this? I can't figure out what this means. BC

2 1

RE: Name Constraints, was Re: [caops-wg] Re: ca signing policy file
by Cowles, Robert D. 13 Oct '05

13 Oct '05

My impression of why we had the constraints were: (1) gridmapfile design flaw (2) the CA's wanted some limitations so as to help divide up the people coming to them ... so that one CA didn't have to issue certs for the whole world (since it's being done on pretty limited budgets). BC > -----Original Message----- > From: Frank Siebenlist [mailto:franks@mcs.anl.gov] > Sent: Wednesday, October 12, 2005 12:09 PM > To: helm(a)fionn.es.net > Cc: Cowles, Robert D.; David Chadwick; Von Welch; Tony J. > Genovese; CAOPS-WG; Olle Mulmo; Joni Hahkala; Jules Wolfrat; > Ron Trompert > Subject: Re: Name Constraints, was Re: [caops-wg] Re: ca > signing policy file > > Sorry, but I have to disagree strongly. > > Having no name constraints and letting any CA issue any name > it wants, > puts all your trusted CAs on equal footing concerning the names they > issue: any CA can overstep its policy boundaries concerning > the issued > names and you have no way to find out. > > Some form of enforced name constraining policy or localizing the > name-issuing to a CA is the only safeguard you have against > any rogue CA > among the zillions that may be present in your trusted CA-directory. > > Wasn't that the main reason that we have our current ca > signing policy > files in the first place? > Did I miss anything? > > -Frank. > > > Mike Helm wrote: > > "Cowles, Robert D." writes: > > > >> that the middleware includes a check of the CA when it compares > >> on DN, then what you say is correct. > >> > > > > This is one of the essential problems with this service that > > has never been addressed as far as I know. name constraints > > "be" an incomplete barrier. > > > > BTW, we have found this omission _useful_ in our past. > > > > We switched from a test, development lab CA (DOE Science > Grid) to a production > > quality CA (doegrids), and we used this property to ease > subscribers' > > transition to the new CA. Lesson? Overlapping name spaces > > might be useful! > > > > > > -- > Frank Siebenlist franks(a)mcs.anl.gov > The Globus Alliance - Argonne National Laboratory > >

2 1