[Pgi-wg] Sec: Agreement on attribute transport mechanisms forAttrAuthZ

[Aleksandr Konstantinov]

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.