rxgk CombineTokens and enctypes (was Re: [AFS3-std] Re: afs3-rxgk-updates for 03)

[Benjamin Kaduk]

On Sat, 3 Nov 2012, Jeffrey Hutzelman wrote:

> On Sat, 2012-11-03 at 14:34 -0400, Benjamin Kaduk wrote:
>> Simon trimmed the bit where Jeff wrote:
>>>> Yes, I would say that "union" is not the right word.  I think you end up
>> If we agree that "union" is not the right word (it sounds like Simon
>> agrees?), then we cannot talk of a "list" of identities, either.
>
> Ok, I don't think that's true.  As you noted, "union" implies an
> unordered set, and that won't do for some of the application needs.  But
> an ordered list would work just fine.  The question is, do we

It was a bit hyperbolic.  Requiring a (single-type) list would 
unnecessarily restrict application freedom to have more complicated 
structures, such as nested lists.  While we *could* do so, I would not 
like to see us do so.

>
> (a) say that a token has an ordered list of identities, specify rules
> for combining identity lists when tokens are combined, and leave it up
> to applications to derive authorization from the identity list when a
> token is used, or
>
> (b) treat the token as having a single, possibly complex, identity, and
> leave it up to the application to determine how to combine them when
> tokens are combined.
>
> I think either option is workable, provided we are clear that it matters
> what order the tokens are presented in, because in (a) the application's
> authorization function may not treat all identities in a token the same,
> and in (b) the combine-identities operation may not be commutative.

I am not fully convinced that we need decide on one of these for this 
document, if the identity information in the token is to be 
application-specific.  Which is not to say that we cannot talk about their 
advantages and disadvantages now to get an idea for where we will go in 
the future.

I don't really care for (a).  If I write T0 = CombineTokens(Alice, Bob) 
when I supply an identity for a token and T2 = CombineTokens(T0, T1) 
otherwise, then a list of identity information would not be able to 
distinguish between CombineTokens(CombineTokens(Alice, Bob), 
CombineTokens(Charlie, David)) and CombineTokens(Alice, CombineTokens(Bob, 
Combinetokens(Charlie, David))).  An application may choose to care about 
the distinction between those authentication paths, and I don't think that 
we should remove the application's ability to do so.

>
>> But, going back and actually searching through the document, "list of
>> identities" only appears in this line where the "list of identities is the
>> union of", so the changes needed actually are localized.  Something like
>> "[user] identity information associated with the tokens are combined in an
>> application-specific manner" should suffice, I think.
>
> Yes, that sounds like it should work.

On my list of new changes to add.

-Ben