RE: Name Constraints, was Re: [caops-wg] Re: ca signing policy file
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@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@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
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@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@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@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 *****************************************************************
participants (2)
-
Cowles, Robert D. -
David Chadwick