Access control use-cases

Norman Gray norman at astro.gla.ac.uk
Wed Jul 12 10:01:13 PDT 2006


Guy,

On 2006 Jul 12 , at 16.42, Guy Rixon wrote:

> On Wed, 12 Jul 2006, Norman Gray wrote:
>
>>> In this
>>> case, the federation downgrades rights of the strongly-certified
>>> identity to those appropriate for the most-weakly-certified  
>>> identity.
>>
>> If I'm understanding you correctly, shouldn't this be the other way
>> around, so that you get the union of the rights that each certificate
>> would give you (monotonicity)?
>
> No, I meant it as I wrote it. If there are resource A which is  
> precious
> and resource B which is less so, then the provider can require a  
> greater
> degree of trust before allowing access to A. If I can get at A with  
> identity
> x, which is strongly certified and I can get at B through identity  
> y (weakly
> certified) then it's OK to let me get at A+B from x but it's a  
> security breach
> to let me get at A+B from y.

Righto -- I think we were at cross-purposes.  Certainly, getting  
access to A+B should be possible only if one can get access to A and  
B separately, so indeed I should not be able to get at A using y.

I read what you wrote as saying that if I request access to A by  
presenting credentials x and y, then I should have my rights  
downgraded to the weakest identity, y, and that I should therefore  
have no access to A in this situation.  My mistake.

>>> Perhaps we need consistent levels of strength of certification for
>>> interoperation? The three levels that seem managable are:
>
> So I'm suggesting that the resource provider set up the special- 
> case code only
> for these three cataegories (expanded from 3 at need) and that a  
> list be
> published of which CAs fit into which category. In fact, it's only  
> necessary
> to list CAs in the top two categories; everything else is in the  
> weakest by
> default.

A problem is that some CAs (for example Thawte) produce certificates  
in more than one of those categories, so you have to examine the  
certificate to determine which category it's in.  But that minor  
complication aside, I see what you mean: some such document would be  
a (substantial!) convenience for resource owners, and save them the  
trouble of reading a CA's CPS and deciding -- after careful thought  
and tearful prayer, of course -- what they were prepared to accept.

All the best,

Norman


-- 
------------------------------------------------------------------------ 
----
Norman Gray  /  http://nxg.me.uk
eurovotech.org  /  University of Leicester, UK



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2427 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/grid/attachments/20060712/5ee8ca08/attachment-0001.bin>


More information about the grid mailing list