[caops-wg] Requirements and rationale for Relying Party Defined Namespace Constraints (signing_policy file)

[David Groep]

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

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.

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

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

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

Given that there is more than one CA in the world, "proving ownership"
of any specific subject DN is impossible. Sorry. Proof of Ownership of
a subject DN is de-facto scoped to one specific CA.

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

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

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

	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 Groep

** National Institute for Nuclear and High Energy Physics, PDP/Grid group **
** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **