[caops-wg] Requirements and rationale for Relying Party Defined Namespace Constraints (signing_policy file)
David Chadwick
d.w.chadwick at kent.ac.uk
Sun Mar 2 15:53:14 CST 2008
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 at 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 at 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
*****************************************************************
More information about the caops-wg
mailing list