Hi David I think this document is fundamentally flawed. This is either because it reflects the grid security infrastructure which is fundamentally flawed, or the document does not and therefore is in error. I refer to the sentence: As many grid authentication and authorization decisions based on X.509 credentials currently only use the subject distinguished name for decision making This is in effect saying that the CA is the SOA and there is no difference between authn and authz. Authn and Authz operate at the same level of granularity. There are no authz certificates, only PKI certs. This is the first fundamental flaw. This must be a flaw in the grid architecture and not in the operation of CAs. But you seem to be placing the responsibility for your merging of authn and authz on the CAs, and blaming them for this. This first flaw naturally leads into the second fundamental flaw. The next issue is that what you are really wanting to ensure is that the correct biological entity has access to a grid resource. This entity can be given one or more globally unique DNs. Further, there is nothing to stop several CAs giving certificates to the same biological entity and using the same DN. If the entity can prove possession of that DN (e.g. based on passport number) then it is OK for multiple CAs to issue certs in the same DN. After all, all the CAs should be doing is authenticating the user. Your current draft forbids this, which again is a fundamental flaw, probably because authn is tightly bound to authz. However, this might be because many CAs are flawed and do not do what they are supposed to, which is authenticate the user and his right to use a specific DN. If the CA behaves correctly you have nothing to worry about. If it does not, then you are correct to worry. If the same DN can be given to two different biological entities by the same or different CAs, then you have a big (unsurmountable) problem. Your entire infrastructure is unreliable since your authentication mechanism is unreliable. Even OpenID does not suffer from this problem. You might not know who the other person is with OpenID, but for sure you know that two different people cannot have the same OpenID. Perhaps you should consider switching to OpenID as your authentication mechanism. OpenID with a strong authorisation mechanism will be far preferrable to what you have today. regards David David Groep wrote:
Dear all,
The rationale for the signing policy file, expressing Relying Party Defined Namespace Constraints, has been documented in a CAOPS-WG draft document. This document is now nearing completion, but as its baseline is now more than two years old, we feel that the list of requirements on the signing policy language expressed in that document may no longer be up to date.
As we discussed in the CAOPS WG, we have updated the document and now invite our major relying parties and middleware providers explicitly to comment on this document. Dave (JSPG), Christoph (MWSG) and Frank (Globus), can you forward this as appropriate?
The latest document draft is at:
https://forge.gridforum.org/sf/go/doc4857 (PDF version attached)
and is really, really, small.
We like to complete this document well before the Barcelona OGF in May, so your timely feedback is really, really welcome. And since the doc is small...
Thanks, DavidG.
PS: We will also ask to "end-user" relying parties via the IGTF and EUGridPMA announcement newsletter.
------------------------------------------------------------------------
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************