Subject: Java binding issues (response to Jack)

From: Michael Smith <[email-masked]>
Date: Wed, 07 Apr 1999 12:48:38 -0400

I think I covered many of Jack's points as well as I 
could in an earlier response to Mayank. A few 
extra topics:

At 11:16 AM 4/7/99 -0400, Jack Kabat<[email-masked]> wrote:

>>4) GSS has two methods for adding mechanisms to
>>credentials: add and add-in-place.[....] Jack's approach, in
>>effect, has only the add-in-place version; if you
>>want a new credential, you add in place and then
>>clone(), or vice-versa.
>
>Again, I don't see this as a problem but a feature :-)
>Clone is a standard Java method used to create a duplicate of an object.
>This is something that Java programmers would be used to and expect to have
>in a class. Unfortunately, there is no equivalent of this in C.

Yes; I could be convinced on this point. As I noted in 
replying to Mayank, our approach was more conservative
and arguably less idiomatic to Java; Jack's strove more
for native fluency. But this is a case where following
the usual Java approach seems to impose no visible cost, 
so why not? 

>GSS treats anonymous name with special behavior (see gss_compare_name). We
>thought it would be useful to allow callers to determine a name of this
>type. Gss_accept_sec_context returns the target name as one of its
>parameters. This name may be anonymous. This methods provides an easy way of
>determining this.

Right again, I think; GSS itself has a reserved name type for
anonymous name, and one can get the name type from a name, 
so Jack is not giving anything away here that isn't already
in GSS. 

>>there's a method, getDefaultMech,
>>returning a mechoid, in GSSManager. Again this doesn't
>>seem to correspond to anything in GSS, as far as I can
>>see.

Jack didn't comment on this one, but I'm repeating it 
in the hope that somebody can enlighten me about why some 
such functionality is _not_ in abstract GSS. Was there 
thought to be some sort of security issue? 

>>10) As the result of an extended discussion some months
>>ago, Jack's and my specifications both contain versions
>>of the per-message and token-establishment calls that use
>>input and output streams rather than byte arrays for the
>>tokens. [....] the calls which take
>>streams as parameters should not block on reading or
>>writing these streams; this implies (inter alia) that the
>>caller needs to ensure that at least an entire token is
>>present in the input stream before calling the method.
[....]
>>(And what does the method do if there isn't a complete
>>token on the input stream, or it can't write the output
>>stream -- rewind it and/or throw an exception? If the
>>latter, with what major status? If not, with what output?)

>The streams are controlled by the caller. The caller is free to decide the
>appropriate behavior of the stream he/she chose to use. 

Well, fair enough, but that's not the problem I'm alluding to here. 
Surely the GSS binding spec needs to specify the behavior of GSS 
implementations with respect to the various combinations
of conditions the implementation may find on the streams, and it also
needs to specify in what state the GSS implementation leaves the streams
after the call, both on normal terminations and on errors.
The problem is that this is a pretty big combinatorial
space, and the existing spec doesn't begin to cover it.
So I wonder if it really buys us enough to justify this amount
of trouble. Perhaps a concrete example of an application that 
would benefit significantly from this approach would be 
helpful. 

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