Subject: GSS: SPI and API

From: Michael Smith <[email-masked]>
Date: Fri, 22 Oct 1999 10:05:47 -0400

I sent off a revised draft of the SPI document to 
the I-D gods yesterday; hopefully this will make it 
through the process. The filename ought to be 
<draft-ietf-cat-gssv2-javabind-spi-02.txt>; 
unfortunately, there has been some confusion 
about numbering and some of you may have a DIFFERENT
-02 version from before Oslo. Get rid of 'em if so. 

I don't consider that there are any show-stopping 
problems for the GSS Java binding that arise from 
the SPI work. Pre-Oslo, I had circulated some suggestions
for what I considered an improved approach to the binding, 
based in part on SPI experience.  Oslo would have 
been the time to discuss those, though, and unless other 
people feel that these are still open issues, I don't 
want to retard the process. The logical structure of 
the interfaces in Jack and Mayank's present 
binding draft can certainly be accommodated
by the SPI and "shims" that use it, even if it isn't
(in my view) entirely optimal. 

The only remaining area where I feel the SPI work 
suggests a change to J & M's document (assuming that's 
the one we move forward) is in the now-familiar area of 
concrete classes vs. interfaces. If I recall correctly, we 
decided (at Minneapolis, was it?) that the binding spec 
itself should consist of a repertoire of interfaces 
rather than concrete classes. J & M have mostly complied 
with this, except for their "factory class", GSSManager, 
which they continue to specify as a concrete class.
This fact presents certain difficulties for me. 
I'll try to outline these now as clearly as I can, 
so that we can plunge right in when we get to DC. 

I envision that GSS implementations will fall into 
two broad classes: "monolithic" implementations, with 
a certain repertoire of mechanisms built in, and 
"shim" implementations which can load mechanisms 
dynamically. (It's the latter class that my SPI work 
is designed to accommodate, of course). 

Now monolithic implementations don't need and can't 
support any mechanism-management functionality. 
Shim implementations do need such functionality. 
Therefore I have specified a "shim" as a class 
which implements the GSS functions of GSSManager, 
and also some mechanism management functions 
which I define in a SEPARATE interface -- separate 
because only "shim" implementations will need to 
use it. 

J & M, however, have defined GSSManager as a 
concrete class incorporating some mechanism 
management functions. I have two problems with 
this: 1) these functions make no sense in the 
context of monolithic implementations, which is 
certainly one class of implementations we want 
to support, and 2) J & M's management functions 
don't seem to me to be quite adequate for the 
purpose.  

Rather than haggling with J & M over the 
management functions, though, I think we should 
do the following:

1) Remove all management functions from their 
GSSManager, and leave it with nothing but pure 
GSS-mandated functionality: i.e. the GSS elements 
common to both monolithic and shim implementations. 

2) Turn it into an interface rather than a class. 

3) My SPI doc will define a supplementary interface -- 
call it GSSMechanismManager -- which "shim" 
implementations will implement along with GSSManager. 
Monolithic implementations will implement only 
GSSManager. 

4) Then we haggle as much as we like over the 
management functions, and don't have to hold the 
core elements of the binding hostage during this 
intensely pleasurable process -- the binding, 
stricto sensu, can proceed merrily down the 
standards track without being held up by the 
management discussion. 

Apart from the management functions, there are a few 
other issues for the SPI itself, and I have a few 
sugestions for the binding as well, but these topics 
don't relate to the interaction of binding and SPI, 
so I'll save them for another occasion. 

--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: Fri, 22 Oct 1999 18:04:18 -0700 (PDT)

Brief comments below...

-Mayank

> rather than concrete classes. J & M have mostly complied 

We had decided this for the Name, Credentials and Context classes only. We
had also decided we had to have a standard way for instantiating
implementations for these. 

> which they continue to specify as a concrete class.

org.ietf.jgss.GSSManager will be the standard factory class for these top
level interfaces. Its easy, logical, and less confusing to developers
since you are introducing new provider based factories in the SPI.

> to support, 

Applications don't want two separate API's for monolithic and
non-monolithic implementations. Our GSS-API has the bare minimum addition
that can *optionally* enable the implementation to be non-monolithic.

> and 2) J & M's management functions 

We're willing to argue that the provider management functionality you're
looking for is already there in the Java language API without us needing
to duplicate it in the GSS-API. Please remember that provider management
is not GSS-API. It's Java Crypto Architecture and that's being built
elsewhere. Unless you have a dire need for something new, its best to not
bloat the API. 

> management functions, though, I think we should 

Please, let's not haggle! Let's discuss this issue on technical and
practical merits.