On Mon, Mar 22, 2004 at 03:15:20AM -0500, Ken Raeburn wrote: > 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".
Agreed. The question in mind is: can we just add mt requirements to the C-bindings? And doesn't the foregoing apply to the base spec also? > >>- 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? On such platforms then the choice of base type for gss_ctx_id_t, gss_cred_id_t and gss_name_t is left to the ABI and not to the implementor. See below. > (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.) One thing I notice now is that the language of rfc2744 seems to make a distinction between recommendations for implementations and recommendations for platforms. It seems that a single ABI for any given platform is desired. I appreciate this but, how is an ABI to be specified for any given platform? No mechanism is provided or discussed for reaching agreement on a given ABI for a given platform, so how could competing implementors agree? > >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? The base spec needs to look after its namespaces. Each bindings spec need to do the same, and if they borrow names from the base spec then they need to specify how that affects the language's namespace. > >> 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. Gross. Also, I just noticed that rfc2744 section 3.1 says that OM_uint32 is at least 32 bits, not exactly. And appendix A guarantees gss_uint32 == OM_uint32 if xom.h was missing. > 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. I think the right answer is: "gss_uint32" is private to gssapi.h (even if visible) and should not be used outside it. Cheers, Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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]
