Subject: GSS: SPI and API

From: Michael Smith <[email-masked]>
Date: Mon, 25 Oct 1999 16:29:38 -0500

Jack's and Mayank's comments on my suggestion (to 
remove management functions from the bindings document
and make it an interfaces-only spec, as per Minneapolis) 
seem to fall into two categories:

1) Who ya gonna call? Con-structors! 

J & M argue that having the "factory class", GSSManager,
be a concrete class gives programmers something to instantiate;
whereas if they specify only interfaces, the programmer 
still needs to know what class to call the constructor 
of. 

I can't see that there's any difference for the programmer. 
Say we follow J & M's approach, and Sun ships a "standard"
GSS implementation as part of the JDK and/or JRE under the 
package name org.ietf.jgss. To use this standard 
implementation, programmers do the following:

(i)  import org.ietf.jgss.*;
     [...]
     GSSManager gm = new GSSManager();

Now say we follow my approach, and Sun ships a GSS implementation
under the package name sun.security.jgss (or something). 
To use this standard implementation, programmers do the following: 

(ii) import sun.security.jgss.*;
     [...]
     GSSManager gm = new GSSManager();

Under either proposal, programmers who need to use some other 
GSS package, whether because of export restrictions or because
they really prefer FooBar, Inc.'s proprietary snake-oil 
crypto suite, or perhaps because they're applets and they've
brought their own mechanisms with them down the wire, do 
the following:

(iii)  import com.foobar.jgss.*
       [...]
       GSSManager gm = new GSSManager(); 

No matter what, you still have to import something, 
and instantiate something. 

2) Provide, provide! (apologies to R. Frost) 

Jack's references to "bloating" the API for management
purposes puzzle me a bit. It was J & M who originally 
proposed to incorporate several flavors of 
AddProvider(java.security.Provider) methods to their 
GSSManager, specifically for use by "shim" 
implementations of GSSManager, even though non-shim 
implementations don't need it and can't support it.

My idea, on the contrary, is to un-bloat the language 
binding in the strict sense by removing management 
functions to a supplementary interface, to be used 
only by those implementations that need it and can 
support it. 

One might tolerate AddProvider() coming along for the 
ride if it were really the only management method one 
needed, but I don't think it quite fills the bill. 
I may not be quite up-to-date on J & M's latest 
version of this call, since I can't seem to get to the 
I-D repository, but based on the latest version of their 
draft that I've seen:

-- it provides no way of reversing the 
operation (removing a provider);  

-- it provides no way of taking whatever 
mechanisms are in a Provider and installing them 
without knowing their Oids; 

-- it provides no way of having multiple
implementations of the same mechanism (which you might 
want to do, e.g., if they provided different profiles of 
options);

-- it provides no way of ordering among the mechanisms 
provided by different Providers (except the clumsy 
expedient of adding them in the order you want them to be 
used); 

-- it provides no way of adding, dynamically and with 
instance scope, an implementation of a mechanism higher 
in the preference order than those loaded system-wide 
when the VM was initialized; 

-- it requires that any mechanism implementations you 
want to add need to be bundled in a Provider before the 
"shim" can assimilate them. 

(This last point may take a little explaining. A Provider 
is just a glorified hashtable, with the names of classes in 
it, and for cases where mechanisms come 
pre-packaged in this particular form of shrink-wrap, might 
as well use it. But if I already have a class implementing 
some mechanism that I want to use, why should I have
to swaddle it in a Provider before I can hand it
over to my shim?) 

These are top-of-the-head observations; others may occur 
to others. Perhaps the lesson here is that while the core
GSS functionality in the binding has been extensively 
discussed, both in the WG and off-line, these mechanism 
management issues have hardly been aired at all. I don't 
think we should hold up the language binding any longer 
while we sort through these issues, and I don't think we 
should send the language binding out into the world with 
an insufficiently thought-through (and, in my view, just 
plain insufficient) management interface. Leave it for 
the SPI phase, where it belongs anyway, and let's move 
the language binding along if we're happy with it as it 
stands, qua binding.  

--Michael Smith
  [email-masked]

==========================================================================
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-masked]

---

From: Mayank Upadhyay <[email-masked]>
Date: Tue, 26 Oct 1999 15:38:19 -0700 (PDT)

>      GSSManager gm = new GSSManager();

I think this is misleading and needs clarification.

Sun would like to work with the IETF to define the specification for the
standard API that Sun will ship. In other words, Sun will ship
org.ietf.jgss.  Applications that need to be portable will instantiate
classes from org.ietf.jgss because that is the IETF defined standard.

A small minority of applications will subclass classes in org.ietf.jgss to
do things that they specifically need. Most will just add functionality to
the existing GSS-API in their JRE using the one hook that we have for the
Java provider model (i.e., GSSManager.setProvider).

-Mayank