On Friday 20 March 2009 12:08, Morris Riedel wrote:

Good morning Aleksandr,

...

-I see no reason for "either". Also it would be nice to define used terms. -AFAIK there are no restrictions for using X.509 proxies (aka PC) in TLS. As long as -we are talking about -standardaized PCs (RFC 3820) of course. -For infrastructures relying on full or partial/restricted X.509 identity delegation PC -(proxy certificate) is -a must. But I see no reason why that should exclude usage of ordinary X.509 -certificates/keys as -mean for identifying (direct or through attributes) communicating parties.

The reason is basically to precisely define what an endpoint supports, if do not define this precisely interoperability will break since there is a big difference using TLS with or without proxies for the authN check. The either

I do code for doing authentication with and without proxies. And I never noticed significant difference.

is a reason to make it more simpler although there is a polymorphic dependency, but this is not always helpful for the implementations.

Example:

(a) For instance, if we would only claim that the UNICORE Gateway (AuthN check for end-users) supports the PGI_TLS w/o knowing if it uses proxies or not:

If you then use your ARC-Client with proxies and access the Gateway you fail, because the AuthN check only checks for full end-entity certificates.

(b) For instance, if we would claim that UNICORE Gateway supports PGI_GSI (so proxies including some newly defined PGI revocation mechanism since this is a general GSI problem, or proxy problem although they have limited lifetime) :

If you then use your ARC client with proxies and access the Gateway you win, because the AuthN check climbs up the whole proxy-hierarchy.

If we use our own UNICORE Client with full end-entity certificates it works as well since PGI_GSI MAY include PGI_TLS (your polymorphic item).

So why not to use last option? Or am I missing something?

### Conclusions and motivation for either:

(a) So clearly every service that do supports PGI_GSI is able to accept client request based on PGI_TLS only

(b) But every service that purely supports PGI_TLS is not able to accept client requests based on PGI_GSI

Bottom line: the either is needed for differentiation including inherently your statement of polymorphism that only indicated 'one direction' or 'is-a' and not the other direction!

If (a) covers (b) then "either (a) or (b)" is not achievable. A.K.