"REGISTRY" back-end for profile info

[Jeffrey Altman]

Joseph Calzaretta wrote:
>> I would want to store [capaths] RAEBURN.ORG as REG_MULTI_SZ with the
>> order-dependent information inside. 
> 
> I hope that means capaths/RAEBURN.ORG should be a key with seven
> REG_MULTI_SZ values under it:

Unfortunately not.  It is the ordering of the "keys" that is what is
lost with the existing profile library that needs to be fixed.

> Or, (and I hope this isn't the case) are you saying that the top-level
> ordering is also important (e.g., capaths/RAEBURN.ORG/ATHENA.MIT.EDU/*
> is strictly before capaths/RAEBURN.ORG/ANDREW.CMU.EDU/*... notice their
> order in my example above)?

The left hand side values in the case of [capaths] should not be
considered top-level.   They are order specific and therefore should
be stored as a whole in a REG_MULTI_SZ.

>> and so is:
>>
>> [libdefaults]
>>         default_tgs_enctypes = arcfour-hmac-md5
>> aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1
>> des-cbc-crc des-cbc-md5 des-cbc-md4
>>
>> I would want to store [libdefaults] default_tgs_enctypes as
>> REG_MULTI_SZ with the order-dependent information inside. 
> 
> Here, I'd think that for maximum portability that
> libdefaults/default_tgs_enctypes would just be a single REG_SZ value of
> "arcfour-hmac-md5 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
> des3-cbc-sha1 des-cbc-crc des-cbc-md5 des-cbc-md4", instead of a
> REG_MULTI_SZ split at all the enctypes.  Otherwise, I'm not sure how to
> distinguish it from something like:
> 
>> [libdefaults]
>>          default_tgs_enctypes = arcfour-hmac-md5
>>          default_tgs_enctypes = aes256-cts-hmac-sha1-96
>> ...
>>          default_tgs_enctypes = des-cbc-md5
>>          default_tgs_enctypes = des-cbc-md4
> 
> More generally, I'm not sure how "foo = bar baz" would be distinguished
> from "foo = bar \n foo = baz" in such a scheme.  If they are supposed to
> be the same (I can see a certain beauty in that) the current profile
> library API doesn't work that way. 
> 
> What do you think?
> 
> --Joe

The current profile library does not have enough type data from the
application to be able to do what it should be doing.

I selected those three cases because those cases represent the three
different models of how the data is treated by the application.

(1) ordered list of pairs stored as block of lhs = rhs entries
(2) ordered list stored as a single right-hand-side
(3) unordered list stored as multiple entries with the same lhs within a
block

Currently, the profile library fails because it does not understand how
the application intends to use the data that it stores.  In fact, I
would argue that the profile library as it currently exists is too
low-level for its own good.

Instead I propose that instead of the application handling the
management of ordered vs unordered lists vs single entries, that the
library do so.  Instead the application should indicate it wants to
obtain the contents of the ordered list of pairs located at "[capaths]
RAEBURN.ORG" and the library would then know how to manage that data.

The current krb5.conf loses because it has no idea what context must
be applied to the [capaths] section since it can't distinguish between
the meanings of [capaths] vs [libdefaults].  They are simply tokens to
the library.

Jeffrey Altman