Re: [kitten] Clarification of gss_add_cred() behavior

[Viktor Dukhovni <[e-mail]>]

On Thu, Mar 19, 2015 at 08:20:18PM -0400, Benjamin Kaduk wrote:

> On Thu, 19 Mar 2015, Nico Williams wrote:
> 
> > GSS_C_NO_NAME.  But then I can never use GSS_Add_cred() to acquire a
> > signle-element credential, and I must always use GSS_Acquire_cred() for
> > that (which is lame for several reasons).
> 
> Perhaps I'm just being slow today, but could you say more about what these
> reasons for lameness are?

    1.  Building a set of things via a different function for the
        first element than then the rest is ugly.

    2.  Calls to gss_acquire_cred() need a mechanism *set*, so one
	ends up building one-element sets for that, and disposing
	of those (though I'm working around that with automatic
	singleton mech sets):

		gss_OID mech = ...;
		gss_OID_set_desc onemech = { 1, mech };

		gss_acquire_cred(..., &onemech, ...);

	Naively, one would allocate an empty set, add the mech to
	that, handle errors, ... use the set, and deallocate it.

    3.  Unclear semantics with respect to error reporting from
	gss_acquire_cred.  Does it report the mechanism-specific
	minor code for the sole mechanism when oid set is a
	singleton?

    4.  The semantics of gss_add_cred() with GSS_C_NO_CREDENTIAL
	for the input cred are underspecified.  (Which mechs are
	use to construct the missing initial cred handle?  Is the
	desired_name ignored when the requested mech is "added",
	and in what sense is it "added" anyway, since other than
	name it would likely already be in that default credential?)

The interface would be simpler and more clear if gss_add_cred()
could just start from zero.

-- 
	Viktor.