Re: KITTEN: IETF 75 - 76

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Wed, Aug 19, 2009 at 09:23:58PM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > > GSS-API is part of the identity selection problem since its the holder  
> > > of credentials.
> > > 
> > > The application/framework will need to drive authentication and select/ 
> > > try credentials as it seems approproate and remember what of them was  
> > > useful.
> > > 
> > > This would work today, if it was possible to get initial credentials  
> > > and list existing/configured credentials
> > 
> > Sure.  An iterator following the same design principles as
> > gss_display_status() would look like:
> > 
> > OM_unit32 gss_list_default_cred_names(
> > 	OM_uint32 *minor_status,
> > 	gss_name_t  *name,
> > 	int	    *more
> > );
> 
> That call looks somewhat restricted to me.

It is.  It should be sufficient however.  (Here name would be an MN.)

If you care about specific mechs you could then call gss_add_cred() with
each name output by gss_list_default_cred_names() and inquire the
result.

> How about something like this:
> 
> OM_uint32 gss_list_default_cred_names(
> 	OM_uint32    * minor_status,
> 	gss_name_t   * name,
> 	gss_OID_set  * mech_oids,
> 	int          * is_default,
> 	OM_uint32    * cred_context
> );

What's "cred_context"?  Would that correspond to the 'more' argument in
my variant?

But yes, it'd be quite useful (though not strictly necessary) to output
a mech OID set and is_default.  As long as only mech OIDs that are all
in the same family (and therefore have the same MN/exported name token
forms) are allowed to appear in mech_oids.

Nico
--