Hi David David Groep wrote:

Hi David,

David Chadwick wrote:

...

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.

I think first of all, we have to acknowledge that the likes of attribute certificates and any other assertions today are bound to an entity based on the subject name of the entity, and the subject name only. In particular, they are not bound to a particular key pair, or to a *combination* of issuer and subject names. The use of anonymous bearer tokens for AuthZ is quite rare in grid practice today...

Thus, the subject name of an entity (so in case of X.509 the subject DN) has a particular meaning, both for authentication and authorization. That means that the subject DN must be unique for each entity -- which is essentially what you said in the second paragraph.

The line you quoted is intended to describe that, possibly indirectly, the authorization decisions are indeed based on the subject DN. The decision may of course be based on much more than just the name, and take into consideration whatever other attributes an entity manages to present, but community practice today is that all such additional assertions are in some way linked to the subject DN, or obtained through an authentication step that is based on the subject DN (when contacting the AuthZ authority/-ies).

I would make two points here. Firstly authz authorities/administrators do not allocate privileges to identifiers (subject DNs). They allocate privileges to people they know (directly or indirectly) or projects they know. Secondly, the authorities then ask for that person's identifier/subject DN so that the privilege can be configured into the system for that person. Thus if the subject DN is unique, there is no problem. However, you do not believe that subject DNs do uniquely identify one person, so your document is there to provide a fix for this.

There have been extensive discussions in the past on whether authentication should be based on the combination of subject and issuer DN, inspired by the fact that the probability of two CAs choosing the very same name for themselves is rather low. But that does not take the fundamental problem away -- it only makes it less likely to occur.

So, let us acknowledge that each subject DN must be uniquely bound to a single entity.

that is the X.509 model. There is no escaping from this.

...

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.

Given that each subject DN must be uniquely bound to a single entity, we must now also acknowledge that the global X.500 naming scheme has broken down.

The model is not broken. It is a simple hierarchical model like the DNS one (although slightly more flexible because it uses typed names, not typeless strings). Noone would say that the DNS model is broken. But it might be that some parties do not conform to the model in their implementations. But that does not mean the model is broken, only that implementations are broken.

There is no way around it -- DNs that are assured to be globally unique by design, based on X.500 naming, are not going to happen anymore. We lost that opportunity ages ago.

I dont know why you say this. It is trivial to invent dozens of globally unique DN naming schemes. So the opportunity has not been lost when you run your own CAs. The solution is to only trust CAs that do conform to the model. Here are some globally unique schemes for your CAs to choose: Email address country name and passport number Microsoft's active directory naming scheme country name and health number or SS number or dozens of other nationally allocated numbers. 128 bit random number name and postal address (and optional serial number for two people of same name at same address) traditional X.599 organisation based scheme. Most universities have LDAP servers and manage quite nicely to give unique names to all their staff and students.

Now, for most applications in the server certificate space, that is not an issue, as DNS provides a globally unique name that can be embedded (anywhere!)

so that is another solution to those above.

in the DN, and thus ensure global uniqueness. So, for CAs operating in the server/web site space, DN subject name collisions are not an issue.

For personal certificates, though, the lack of global namespace has a profound impact on the way we need to structure DNs.

I disagree. There is nothing to mandate any DN structure. Most software will work with most naming schemes.

"Further, there is nothing to stop several CAs giving certificates to the same biological entity and using the same DN. "

is in theory a true statement.

Nothing wrong with this. This is perfectly good practice. In practice, however, this is utterly

useless: CAs are independent entities, and it is de-facto impossible to ensure that a DN used by one CA is not assigned to a different entity by another CA. Mr "John Smith" will likely have this problem. If a CA were to assign a DN that contained just "CN=John Smith"

It would be a crap CA. End of story. Dont use it. Dont let such a CA join your grid trust scheme. End of problem. There are spades that dig earth, and spades that break when you dig earth. So dont use spades that break. Tell people which spades to buy that do dig earth and dont break. to a person that is,

indeed according to his passport, called "John Smith", does his passport prove "possession" of this DN? Must the CA verify with all other CAs in the world that he is indeed the owner?

You are getting confused and missing the point. The passport provides a unique identifier, but not a unique name. So you cant use the non unique name in a passport to create a unique DN. You would be stupid to even try, since it breaks the rules of hierarchical naming (that every parent only has one child with each unique name) Does the list of "all CAs in the

world" exist?? (if yes, I would dearly like to have it :-) Will a CA give out the subscribers sensitive information to all other possible CAs in the world so that they can ensure uniqueness? Or will you, as a CA manager, send out the applicants sensitive data over, say, CNN so that any potential CA in the world can pick it up and check out any name collisions??

You have completely missed the plot here and are getting ridiculous.

Given that there is more than one CA in the world, "proving ownership" of any specific subject DN is impossible.

No its not. You are confusing DN with CN. There are thousands of the same CNs, but a DN must uniquely identify just one individual. Sorry. Proof of Ownership of

a subject DN is de-facto scoped to one specific CA.

This is the broken model that the PKIX group introduced. However, if this is the model that you want to have, then you must always use issuer-subjectDN as the unique identifier of a person. So, if you think subject names are broken, dont use them on their own. I cant understand why you would continue to use something you think is broken when it is quite simple to fix it by always using issuer-subject DN. I think your are somewhat schizophrenic about the subject DN uniqueness issue. Either they are unique or they are not. You seem to be saying they are not, but then say we will ensure they are unique by creating some rules to make sure they are. In which case they are unique. You just happen to be supplementing the X.500 rules with some additional rules of your own to guarantee uniqueness.

...

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.

The binding to authZ is irrelevant here. What this draft states is, indeed, that CA MUST NOT assign DNs that are indistinguishable from the DNs of other CAs -- at least within the scope of a single relying party or bridge policy auhority. That's the whole idea of a policy bridge authority (such as the IGTF).

In a bridge CA architecture that is supported by technical (certification) means, and the very same name constraints hold, and are then encoded in the SubTree restrictions. In a policy bridge model, this enforcement can only be done at the relying party's end, using relying-party defined constraints on the name space.

"If the CA behaves correctly you have nothing to worry about."

The point is that a CA, by definition, cannot behave in the way you want it so -- with the demise of X.500 naming we lost that option.

I simply dont understand what you mean by "the demise of X.500 naming". You are using X.500 naming. Every X.509 cert in the world uses X.500 naming. SO X.500 naming is thriving quite well. X.500 says nothing about what name forms you should have. Its all non-normative annexes. Those annexes have died, but then they were never part of the standard anyway.

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

The problem is not exactly unsurmountable. The relying party defined namespace constraints (and the GT signing_policy file) are exactly means that we have to get over this issue and build a working policy bridge infrastructure, where the policy bridge authority ensures uniqueness of DNs by limiting the namespace -- and as it is a policy bridge, and not a CA bridge, this enforcement is done at the receiving end of the assertions. That's the use case for RPDNC and thus this document.

...

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

And how would you envision proving ownership of a DN?

Its very simple. If you already have a cert, then sign something. If you dont have a cert, you prove ownership of one or more RDN components that the CA knows how to turn into a globally unique DN. The same RDN components could be used to create different DNs by different CAs, so then you would be the lucky holder of several unique subject DNs.

...

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

OpenID essentially guarantees uniqueness based on DNS naming again. Fine. We could have used (nad actually do strongly encourage) the use of DNS derived names to guarantee uniqueness amongst DNs, with most of the "new" CAs using domainComponent based prefixes for their subject name. But since there is no technical reason to enforce DNS-based prefixing, the policy bridges and RPs today also allow other RDNs to build unique names. Fine. There is really no issue there.

I hope this re-clarifies for you -- and I think that this discussion somehow proves that the RPDNC use case document is needed. Although including all text above in the doc seems overkill to me :-)

I would summarise your position by saying that you believe in globally unique Subject DNs, you must have them for the grid to work, and so you are setting up rules to ensure that you definitely do have them. regards David

Cheers, DavidG.

...

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

Hi Mike there is more to it than what you propose, and this is the second point I make ie. whether 2 different users can be given the same DN or not by different CAs (we assume that the same CA will be competent enough to not do that). If the answer is yes, then your whole infrastructure is broken. If the answer is no, then the sentence below should be changed if, as you point out, there is much more to decision making than the DN on its own, such as lists and attributes that are used by authz services. regards David Mike Helm wrote:

David Chadwick writes:

...

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

Is there anything more to this than a different interpretation of "only use ... for decision making" here?

My understanding of current grid practice (based on a mixture of hearsay, imagination, dreaming, rumor, and paranoia) is that X.509 subject names, and subject names only, are used as a primary key to lists/collections of attributes that authorization services keep. Some of these cases are pretty simple and some are complex databases. There are a few cases where these certs are also used directly for an authorization decision - all the ones I know of are on the boundaries between grid and non-grid services, or outside of grids altogether.

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

Mike Helm wrote:

David Chadwick writes:

...

Hi Mike

there is more to it than what you propose, and this is the second point I make ie. whether 2 different users can be given the same DN or not by different CAs (we assume that the same CA will be competent enough to not do that). If the answer is yes, then your whole infrastructure is broken. If the answer is no, then the sentence below should be changed

Well, in the long long ago, the signing policy was in fact designed for just this situation: CA A & CA B both certify subject name X. Relying party has to decide which one of these versions of X it is willing to trust (or both or neither).

We don't allow this problem to exist in IGTF accredited CAs by policy.

A very sensible policy. regards David And it is generally agreed that such collisions are so

undesirable that this policy is not controversial. There is nothing that can be done about non-accredited CAs (such as government or commercial CAs for instance), altho many of them constrain their namespaces adequately so as not to be a problem.

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