Re: [kitten] Clarification of gss_add_cred() behavior

[Nico Williams <[e-mail]>]

On Thu, Mar 19, 2015 at 03:50:22PM -0400, Benjamin Kaduk wrote:
> Nico says:
> > The problem is the spec effectivel says that when input_cred_handle ==
> > GSS_C_NO_CREDENTIAL then desired_name is ignored.  This seems like a
> > mistake.
> 
> My reply is that GSS_C_NO_CREDENTIAL means the default credentials which
> in turn means the default name.  There's no use for an explcit name when
> the default name is being used.

But I have a desired_name, and if it is the GSS_C_NO_NAME, then sure,
that means "default", but if it's not, then gss_add_cred() is useless.

Think about what the quoted RFC text means...  First GSS will acquire a
default credential (for what mechanisms?  not stated!).  THEN it will
try to add an element for the desired_mech... which element should
already be present, therefore GSS_Add_cred() with input_cred_handle ==
GSS_C_NO_CREDENTIAL -> same as GSS_Acquire_cred() with desired_name ==
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).

This totally conflicts with the stated purpose of GSS_Add_cred():

   GSS_Add_cred() enables callers to construct credentials iteratively
   by adding credential elements in successive operations, corresponding
   to different mechanisms.  This offers particular value in multi-
   mechanism environments, as the major_status and minor_status values
   returned on each iteration are individually visible and can therefore
   be interpreted unambiguously on a per-mechanism basis. A credential
   element is identified by the name of the principal to which it
   refers.  [...]

Nico
--