RE: Name Constraints, was Re: [caops-wg] Re: ca signing policy file
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@ggf.org [mailto:owner-caops-wg@ggf.org] On Behalf Of David Chadwick Sent: Wednesday, October 12, 2005 10:57 AM To: helm@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@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
*****************************************************************
"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!
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
Frank Siebenlist writes:
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.
If you don't / can't trust the CA - don't use it.
If you could trust a CA for "some" names, you may be able to trust more CAs and more easily... -Frank. Mike Helm wrote:
Frank Siebenlist writes:
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.
If you don't / can't trust the CA - don't use it.
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Frank Siebenlist wrote:
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.
Frank if the names are completely unique random numbers (such as a hash of a public key), then I dont see your problem with a CA overstepping the boundaries. Can you be more specific about what the problem is. A CA is a certification authority, not a naming authority. The purpose of a CA is to bind a name to the public key. The CA should not be responsible for allocating the name, only authenticating that the user has the right to use the globally unique name it claims. If the name is a hash of the public key, then anyone can claim this right through POP. If the name is based on a passport of SS number or email address then the CA can authenticate this. In this type of scenario name constraints are not that useful. They can be introduced if you want to say things like only the US CA can issue certs based on US passport numbers. One of the ways that PKIX went wrong was by giving the CA the naming authority role as well as the certification role, because it reduced the liability of the CA (it did not have to do a full job anymore). regards David
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!
-- ***************************************************************** 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 *****************************************************************
On Oct 12, 2005, at 13:41, Mike Helm wrote:
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!
Overlapping namespaces considered harmful -- The two CAs were not of equal "quality" (security and assurance level). The existing mechanisms did not enable a service to authorize subjects from the better CA to a different level than subjects from the inferior CA. (Unless one of those levels was "zero.")
Matt Crawford writes:
The two CAs were not of equal "quality" (security and assurance
How do you measure the effect of this "quality" on certificates? (Leaving aside the tools for doing authorization / eval on certificates, which are both lacking & out of scope imo.)
Mike Helm wrote:
Matt Crawford writes:
The two CAs were not of equal "quality" (security and assurance
How do you measure the effect of this "quality" on certificates?
Good question. I had a research project 5 or more years ago in which we built an expert system to evaluate the amount of trust that you could place in (or quality of) certificates from a given CA. This worked by evaluating the CPS and coming up with a trust quotient (a value between 0 and 1), where 0 meant completely untrustworthy (like those Thawte certs quoted earlier) and 1 meant completely trustworthy. This trust quotient could then be plugged into the authorisation decision process. regards David
(Leaving aside the tools for doing authorization / eval on certificates, which are both lacking & out of scope imo.)
-- ***************************************************************** 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 *****************************************************************
When you say "name collisions", you must be referring to either compromised CAs or errors as name collisions should not occur... By using both the Subject's DN as well as the CA in the authorization policy, you're essentially negating the ability of the PKI to define global names: if you believe in the pkix/x509 religion then after the path validation, the CA falls out of the equation. Now Mike's idea of using some random names for subjects is good but doesn't solve the problem as it would still allow any "trusted" CA to bind a different key to the same random-name. Maybe random names for subjects should be used together with name constraints. 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. -Frank. Cowles, Robert D. wrote:
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@ggf.org [mailto:owner-caops-wg@ggf.org] On Behalf Of David Chadwick Sent: Wednesday, October 12, 2005 10:57 AM To: helm@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@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
*****************************************************************
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
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.
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. 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
Frank Siebenlist 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. 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. regards David
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.
-- ***************************************************************** 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 *****************************************************************
On Oct 13, 2005, at 5:29 AM, David Chadwick wrote:
Frank Siebenlist wrote:
I don't care about the collisions - that's a non-issue as far as I'm concerned. [...] 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.
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.
I have to agree with David here. The issuance of the certificate is an authentication issue, not an authorization one. The CA asserts that it has verified teh identity of the person to whom it has issued the cert, and in principle there is no problem at all with more than one CA verifying the personal identity of an individual to whom it issued a cert. So it is not a matter of impersonation -- if one of your other trusted CAs verifies the identity of your director and issues him or her a certificate, this is redundant. If that CA does so maliciously or in error, it has violated the conditions for being a trusted CA and should be dropped. That's what CA trust is about. As for the issue of naming constraints, I see two issues: a technical one, and a practical / best practices one. If we agree to the above, then the technical issue appears to boil down to whether openssl 0.9.8 is common enough to allow naming constraints to be used to flag potential problems: "hey, I happen to notice that this cert does not conform to x and so expected pattern" -- then the next step would be either to (a) downrate the capabilities of the user based on that information, or (b) simply print an informational flag. Are there any other issues? Alan Sill TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
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
Frank Siebenlist writes:
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.
Of course, if you think the names in a certificate have an inherent meaning, and you don't use the issuer in the evaluation, you are stuck. This is the defect in the grid authentication scheme. Trying to fix this with name constraints is backwards in my opinion.
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.
Just what do you think we have now?
Mike Helm wrote:
Frank Siebenlist writes:
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.
Of course, if you think the names in a certificate have an inherent meaning,
The idea of using unique but meaningless names in the certs is a good one, but it doesn't solve the issue really... It definitely makes the initial vetting easier, but after you have assigned some uuid to some key, and that key-holder happens to be the lab director, then it is no longer a meaningless name for subsequent authorization decisions. It then becomes important that no other CA will issue that same uuid to the key of a different key-holder, which should be "enforced" either by "Thy shall not..." policies or by adding the CA somehow in the equation for real-time enforcement.
and you don't use the issuer in the evaluation, you are stuck. This is the defect in the grid authentication scheme. Trying to fix this with name constraints is backwards in my opinion.
Are you suggesting that we should keep the CA always with the DN for all the authorization decisions? (Essentially pushing the policy enforcement of name+CA to the authorization stage and throwing-in the towel as far as the pkix/x509 global-naming dream is concerned...)
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.
Just what do you think we have now?
That is the real question then: Can the EGEE/FusionGRID/OSG/TeraGRID/??? live happily with the "Thy shall not..." model? If so, life is easy, no need for those pesky ca signing policy files, and let's move on... If not, or maybe not, or sometimes not, should we move to a model where the CAs remain in the authorization picture and asserted names should always be considered in the context of the issuer? -Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Frank Siebenlist writes:
Are you suggesting that we should keep the CA always with the DN for all the authorization decisions? (Essentially pushing the policy enforcement of name+CA to the authorization stage and throwing-in the towel as far as the pkix/x509 global-naming dream is concerned...)
Yes. To all. As DC mentioned there is available to us a global naming strategy. It is not perfect and it has some side effects, but it can at least reduce some of the human confusion. However, you still have to include the issuer in any decision, because you have to have some assurance that the binding was legitimate. We don't yet (won't ever?) have an a priori way of knowing that.
If not, or maybe not, or sometimes not, should we move to a model where the CAs remain in the authorization picture and asserted names should always be considered in the context of the issuer?
I think this is the safer of the 2 choices you offered.
Mike I can put a different slant on this, which is, the strength of authentication (and other factors such as location, time of day etc.) should be a component of authorisation decision making. For example, I logged in at an Internet cafe at midnight using un/pw and I want to delete an employee from the employee database. Access denied. I logged in using my PKI certificate and smart card from a computer in the administration department at 10am and I want to delete an employee from the employee database. Access granted. So it is not too unreasonable to include the name of the CA in the authorisation decision making, once we accept that they are trusted to different levels. This is not too difficult to enforce with a general purpose authorisation PDP (in fact we are currently working on a project with Uni of Manchester to implement strength of authentication in authorisation decision making) regards David Mike Helm wrote:
Frank Siebenlist writes:
Are you suggesting that we should keep the CA always with the DN for all the authorization decisions? (Essentially pushing the policy enforcement of name+CA to the authorization stage and throwing-in the towel as far as the pkix/x509 global-naming dream is concerned...)
Yes. To all.
As DC mentioned there is available to us a global naming strategy. It is not perfect and it has some side effects, but it can at least reduce some of the human confusion.
However, you still have to include the issuer in any decision, because you have to have some assurance that the binding was legitimate. We don't yet (won't ever?) have an a priori way of knowing that.
If not, or maybe not, or sometimes not, should we move to a model where the CAs remain in the authorization picture and asserted names should always be considered in the context of the issuer?
I think this is the safer of the 2 choices you offered.
-- ***************************************************************** 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 *****************************************************************
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@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@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 *****************************************************************
David Chadwick writes:
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.
No I think this is both a misrepresntation and a misunderstanding of what Thawte WOT does, which should be looked into on its own account. Their process is at least as rigorous as the stronger Grid European CAs. But I'm not interested in following that up - anyone interested can research their process for themselves.
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.
Sorry, but you're not the only David Chadwick on the planet. I don't happen to know any others, but I am confident we can turn one up. 411.org shows a few in CA, for example. I worked in a group in LBL that had 3 people with the same first and last name, completely unrelated; a group of about 25 people. Focusing on names is a rathole.
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.
I can agree with that; we proposed a system like that in late 2001 for our Grid users. Rejected. We have brought it up at other times, but people have raised the issue of spam address harvesting because of the public nature of the certificates. BTW, basing a system on email addresses remains quite problematic. We get about 10 email bounces a week from the certificate lifecycle service of our CA. I have tried to push the issue of revoking these certificates, and it never flies in our PMA. And for good reason - there are many ways for email to fail. It took 6 months or more to sort out an argument between one mail service, which was ruthlessly enforcing certain DNS rules, and another, which had carelessly configured their domain and MX rules (mistakenly, but a common configuration). The scientists and the CA were stuck in between.
Frank random is different from unique. If the random name is also unique (or has a statistically rare possibility of collisions) then the CA name is irrelevant isnt it? Since every CA can then have the full name space to allocate within and there is no way of partitioning it. regards David Frank Siebenlist wrote:
When you say "name collisions", you must be referring to either compromised CAs or errors as name collisions should not occur...
By using both the Subject's DN as well as the CA in the authorization policy, you're essentially negating the ability of the PKI to define global names: if you believe in the pkix/x509 religion then after the path validation, the CA falls out of the equation.
Now Mike's idea of using some random names for subjects is good but doesn't solve the problem as it would still allow any "trusted" CA to bind a different key to the same random-name.
Maybe random names for subjects should be used together with name constraints.
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.
-Frank.
Cowles, Robert D. wrote:
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@ggf.org [mailto:owner-caops-wg@ggf.org] On Behalf Of David Chadwick Sent: Wednesday, October 12, 2005 10:57 AM To: helm@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@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
*****************************************************************
-- ***************************************************************** 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 (6)
-
Alan Sill -
Cowles, Robert D. -
David Chadwick -
Frank Siebenlist -
Matt Crawford -
Mike Helm