Re: KITTEN BOF at IETF 60?

On Sunday, Mar 21, 2004, at 20:40 US/Eastern, Nicolas Williams wrote:
>>   If a mechanism doesn't provide out-of-sequence detection, can I use
>>   gss_get_mic in two threads with the same security context, without
>>   ensuring that the calls aren't fully serialized?
>
> This should be implementation specific, though I'd have the spec
> recommend yes, even when using oos detection (oos tokens aren't
> necessarily a problem).

If it's implementation-specific, then as far as writers of portable 
applications are concerned, it might as well be "no".

>> - The description of equality comparisons in section B.3 makes me
>>   shudder.  I'm not even sure what it means.  As far as I can tell, if
>>   your machine lets you have two objects (pointers, integers, floats)
>>   that compare equal with "==" despite having some bits that are not
>>   identical, then you have to fix up those bits to always be equal.
>
> Sure, but this is really a simplification that I think most of us 
> should
> be willing to live with.  On any platform where pointers to different
> things are of different sizes and so on this spec may not be workable,
> but that's ok; implementors on those platforms may have to make their
> own bindings, or they may find the Java bindings useful.

I don't see any possible benefit to this that doesn't rely on other 
platform-specific knowledge.  And it means the ABI portability 
recommendations may be difficult (or possibly impossible?) to implement 
on some ISO C platforms.  Is being able to use memcmp on two handles 
(not the data pointed to, but the handles themselves) instead of "==" 
really what was intended in the first place?  (Given how "const" is 
used in this RFC, I'm not confident of that.)

> Well, on IP32, IP64 and LP64 platforms it's possible to give the
> implementor a choice of integer and pointer types for the handles and
> still maintain ABI compatibility.  That's most every platform.

What about platforms where integer function arguments are passed in 
data registers and pointers in address registers?

(Granted, we're talking about recommendations for better compatibility, 
not an actual ABI specification.  So if it can't actually work on all 
systems, it's not a fatal flaw.)

> Not only this, but also, the GSS_C_*, GSS_S_* and gss_* names originate
> from RFC2743.
>
> The base spec should have an allocation policy for extensions' names.
>
> And the bindings specs should apply the base spec's policy towards the
> language's namespace.

This needs some care.  The base spec should outline the operations 
needed, but shouldn't get into namespace issues too much.  For example, 
you won't find the name "gss_wrap_size_limit" anywhere in the Java 
interface.  Instead, the GSSContext interface includes a 
getWrapSizeLimit operation.  The handling of extension names in Java 
might be quite different from in C.  And who knows what the Scheme 
bindings might look like?

>>   Can I use gss_uint32 in my code?  (True, there's no guarantee that
>>   it's the same as OM_uint32.)
>
> There should be.  It's implicit in the name.

No, what's implicit in the name is that both should be unsigned 
integral types of at least 32 bits.  On an ILP32 system, one could be 
unsigned int and the other unsigned long.  Mostly compatible in C, but 
could trigger diagnostics if you use pointers or multiple declarations. 
  But if the code that interacts with the GSS-API C bindings is written 
with the assumption that they could be different types, then it should 
be safe.

But the other part of my point was, since the gssapi.h provided is 
apparently what is required to be supplied to application writers, then 
gss_uint32 must be available, even though it's not directly used in the 
API (and if xom.h is available, isn't indirectly used either), or even 
mentioned anywhere outside the appendix.

Ken

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]