Re: KITTEN: IETF 75 - 76

[Love Hörnquist Åstrand <[e-mail]>]

17 aug 2009 kl. 01:51 skrev Nicolas Williams:

> On Sun, Aug 16, 2009 at 12:26:34AM -0600, Shawn M Emery wrote:
>> Love had given a set of new work items that would be of interest, as
>> follows:
>>
>>   1. initialization/new credentials
>>   2. listing/iterating credentials
>>   3. exporting/importing credentials
>
> (1) is a complex matter as it requires interaction with users and  
> needs
> to cover such things as principal name, password, new password, PIN,  
> PIN
> change and other prompts.  A design is certainly possible.
>
> (2) is really listing of principal names for which the caller has
> credentials (we can already list mechanisms for which the caller has
> credentials).  This is likely a difficult thing to design since we  
> will
> want to be able to control what principals GSS_Accept_sec_context()  
> can
> accept sec contexts for, and that means a significant revamp of the
> semantics of CREDENTIAL HANDLEs _or_ a replacement for
> GSS_Accept_sec_context().

accept sec context is not really intresting since it doesn't make  
thinks not work. init sec context however it mostly useless since the  
consumers don't know about what credentials they have.

have a list of mechs there is credentials for is also mostly useless,  
i have [e-mail] (Kerberos), SU.SE\lha (NTLM), KTH.SE (Kerberos) E.KTH.SE 
  (sasl-digest-md5),  
[e-mail]1:EA35DAB08BD8EC833C160FAFCDF03E4B13F72D6B (Kerberos) any  
many other, knowing that I have some Kerberos credentals is mostly  
useless.

Its not even possible to build ui to do specific selection, or  
selection other then providing a text field that you can do  
gss_import_name(GSS_C_NT_USER) on and hope that it work.

>>   4. error message reporting
>
> Yes.  (I still believe in the "PGSSAPI" idea where, in the C bindings,
> we change the semantics and type of the minor_status argument,  
> though in
> a binary backwards compatible way.  I can expand if desired.)

Lets redo the api, ISC is broken as it since there is no way to add  
new tokens.

>>   5. asynchronous calls
>
> Developers can use threads to work around the lack of these, so it  
> seems
> to me that these should be a lower priority.

I disagree, threads consume lots of resources that and are very  
complicated to use.

>> ...along with Alexey's recent request for policy/encryption strength.
>
> Yes.  This should be, IMO, a high priority.

And not over engineered. Let's solve the SASL problem and nothing more.

>> We are looking for authors and editors for any of these new items or
>> something else that you would like to see developed within KITTEN.
>
> I'll edit, but I need co-authors who'll contribute text, API designs,
> and energy to the list.

Love