Credential cache searching, ccapi and file caches

[Nicolas Williams]

On Wed, Jul 14, 2004 at 04:58:29PM -0400, Sam Hartman wrote:
> I'd actually assumed you'd modify krb5get_credentials to accept a null
> client principal, modify gss_init_sec_context and all the applications
> in our tree.

Right, the GSS-API has a GSS_C_NO_NAME which corresponds to the default
principal of the credentials store.  The krb5 API should have this too
(and, to some extent, it does, for krb5_rd_req() anyways, no?).

> This would mean that some applications would not support credential
> searching explicitly, but everything that continued to work would
> still work.  It would also mean that in the new world order, correct
> applications would have to call less functions (no
> krb5_cc_get_principal), which I consider a change for the better.  

Much like GSS-API apps that use GSS_C_NO_CREDENTIAL and GSS_C_NO_NAME.

Initiator non-GSS_C_NO_CREDENTIAL credentials acquired for GSS_C_NO_NAME
should continue to reference whatever principal name was determined at
credential acquisition time.

Initiator GSS_C_NO_CREDENTIAL creds should always reference whatever is
the current default principal for the current credential store at time
of use of the credentials.

The same does not quite apply to acceptors since for acceptors the NULL
credential typically has a very different meaning than for initiators.

> Finally, if an application did want a particular client principal it
> would use the relatively intuitive interface of requesting that
> principal explicitly.

Right.

I say follow the GSS-API model on this.

Cheers,

Nico
--