Re: GGF's extensions to GSS in Public Comment

Von Welch wrote:

> But for GSS mechanisms that don't have kernel support for their
> creentials stores and use environment variables, this isn't the
> case. A process might decide to clean up its environment for a number
> of reasons and accidentially effect the GSS mechanism's current
> credential store or fail to pass the meaningful env variable to a
> child process as in SSHD.
> 
> This is what led us to have a mechanism that allowed the GSS mechanism
> to tell the calling application that a particular env variable was
> meaningful to it so that a well behaved application could treat that
> variable appropriately.

Maybe I'm misunderstanding, but wouldn't this mean that the application
has to make assumptions about the underlying mechanisms implementation
in order to get the variable correctly?

> 
> You are right in that our use of environment variables was focused on
> a couple of specific mechanisms (GSI & Krb5) in which we were
> interested. I agree the approach does not generalize well to
> mechanisms that use other methods besides env variables.

I think that specifying the use of environment variables as an
interface for manipulating the configuration of the mechanisms
is a really ulgy solution.   Use of environment variables may
be acceptable in a particular implementation of a spec, but they
should definitley not be part of any standards document for a
generic interface such as this.

-Wyllys Ingersoll

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]