Re: KITTEN: IETF 75 - 76

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

On Thu, Aug 20, 2009 at 05:09:19PM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > It is.  It should be sufficient however.  (Here name would be an MN.)
> 
> An MN means that it refers to a singular identity/name in one
> particular namespace, it does _not_ imply a single mechanism (oid) only.

I made that clear further down where I referred to mech families.

> A Kerberos principal is going to be an MN for the rfc1964/rfc4121 mech OID,
> for the pre-rfc1964 mechoid and for the IAKERB mechoid.
> 
> But I would NOT want to require the name to be an MN here!

How could it be anything but?  Oh sure, for a family of mechanisms the
name could be one that's imported with GSS_Import_name() and a
mech-specific name type OID, or GSS_C_NULL_OID, and not canonicalized.
But such a name would likely not be useful for credential acquisition
for other mechanisms outside that family.

> I do not want to require that the returned name is an MN (because this
> would take away the possibility for the gssapi mechanism to
> select/negotiate the best common mechanism and _require_ the user to
> perform an a-priori conscious selection.

I don't follow this.

> Thinking about it, I would actually want to add two more function
> parameters:
>        OM_uint32    * lifetime,
>        gss_bufFer_t   descriptive_message,
> 
> to allow application writer to show additional information in
> selection UIs that they show to users.  :)

What would descriptive_message have?  A description of the
mechanism/mechanism family?

What about lifetime?  Why is that necessary?  Sure, we could put all
outputs of GSS_Inquire_cred*() here.  Heck, cred_usage seems a lot more
useful that lifetime in this context.