Constrained Delegation with certificate and GSS API

[Puran Chand]

I see gss_import_name() put the name_type to gss_union_name_t->name_type
and cert_data in gss_union_name_t->external_name.
However I don't understand how this should pass down from GSS API
(gss_add_cred_impersonate_name) to krb5
API(krb5_gss_acquire_cred_impersonate_name).
I see gss_name_t passed down to krb5 API isn't what received in GSS API.
Its gss_union_name_t->mech_name and the same is converted
into krb5_gss_name_t eventually.
And I believe  krb5_gss_name_t  is constructed into
krb5_gss_import_name/imp_name.c, IDK what would be the right place to store
cert_data in krb5_gss_name_t, should the name_type be copied to
krb5_gss_name_t->krb5_principal->type and cert data to
krb5_gss_name_t->krb5_principal->realm?

-Puran

On Tue, May 12, 2020 at 3:07 AM Isaac Boukris <iboukris at gmail.com> wrote:

> On Mon, May 11, 2020 at 6:55 AM Puran Chand <puran157 at gmail.com> wrote:
> >
> > I don't see a name type for certificate as per
> https://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html#name-types
>
> The idea was to add a new name type.
>
> > Also as I understand, I need to get rid of
> gss_acquire_cred_impersonate_cert and instead invoke relevant code from
> gss_acquire_impersonate_name based on name type.
> > LMK your thoughts.
>
> Yeah, the caller would import the cert data with the new name-type and
> pass it to gss_acquire_cred_impersonate_name() as desired_name.
>