Exporting gssapi context, take two

[Nicolas Williams]

On Wed, Apr 28, 2004 at 04:04:53PM -0500, Douglas E. Engert wrote:
> Nicolas Williams wrote:
> > On Wed, Apr 28, 2004 at 01:46:55PM -0500, Douglas E. Engert wrote:
> > Generic extensions should be based on generic extension objects defined
> > by IETF (or other) specifications and identified by OIDs
> > (runtime-typing, if you will).
> 
> I agree. And I really don't like the use of the mech specific interfaces. 
> As it makes it harder to use arbitrary mechanisms if the application still
> has to link in mech specific routines.  Although I don't see how one could
> mandate not allowing them. There will be some cases that are missed.  
> 
> We should try and learn form experience and try and get a list of all the 
> known mech specific routines that have ever been used! We might find
> that many of these could be handled by new generic routines. The saving
> of the delegate credential is a prime example.

Yup.  Though I wouldn't necessarily want to standardize our GSS
authorization interfaces (informational RFCs might suffice)...

> > 
> > I think the interfaces to mechanism-specific-but-platform-independent
> > extensions should be platform-independent.  This is not a slam dunk
> > argument for the runtime-typing approach (as I'm sure that Sam will
> > point out), but it's a pretty good argument, I think.
> > 
> > And while this gss_get_mech_<object>() approach can work, whether the
> > result is platform/inplementation-independent will depend on the
> > interfaces that operate on the mechanism objects.  Also, the mechglue
> > layer should do object handle validation and save the mechanisms the
> > trouble of doing it too, but your proposal means that the mechanisms
> > should do handle validation too.
> 
> But there may not be a mechglue layer, therefore each mech needs to 
> do all the checks. 

True, but that could be a compile-time option that you might turn off if
you knew you were going to use the mech with a mechglue layer.

> > 
> > I still prefer the other approach; I may end up compromising on this
> > eventually, but I want to hear more about why one way is better than the
> > other.
> > 
> > > There would be one of these routines for the context too.
> > 
> > Since the API and SPI correspond there are actually three objects you
> > might want to do this for: names, creds, security contexts.
> 
> I forgot the names. Any others? 

No, just names, creds and contexts.

I doubt we'll want to extend the OID, OID set and/or buffer types :)

Nico
--