Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 07 Dec 2008 21:21:08 -0500

--On Friday, November 28, 2008 02:23:43 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>
> Nicolas Williams writes:
>> That was Sam's point -- the OS can provide SASL and GSS frameworks,
>> but there's no way to force third parties to use them.
>>
>> Now, one possible answer is: not our problem. But I don't like that
>> answer.
>
> I don't understand.
>
> What's the point of the hashed OIDs as names? I thought you were saying
> that their advantage is that they permit such applications to use new GS2
> mechanisms.
>
> In my experience that's pointless. Those applications explicitly don't
> want to use new mechanisms, so making it easy is pointless. You seem to
> agree, or am I misreading? But what's the point of the hashing then?

You seem to be saying that your experience is that every SASL application 
implementation throws modularity out the window and implements everything 
itself.  If that were true, then abstractions and modularity would be 
pointless, but it is _not_ true.  I use applications every day which depend 
on SASL framework libraries, which depend on GSS-API libraries, which 
depend on Kerberos libraries.  No one implements everything themselves.

The point of modularity in a SASL mechansim framework is to allow me to 
drop in new mechanisms.

The point of modularity in a GSS-API mechanism framework is to allow me to 
drop in new GSS-API mechanisms.  If you think no one does this, go ask 
Martin Rex to tell you about all the different GSS-API mechanisms his 
customers have come up with.  Make sure you have some time; it's a long 
list.

The point of OID-derived mechanism names is to allow me to drop in new 
GSS-API mechanisms and start using them with my SASL framework and 
applications, without having to write code or internet-drafts or know who 
IANA is or why I should care what they think about whether I can use my 
company's site-specific authentication mechanism to access my email server.

The argument you're making seems to be "abstractions are hard, modularity 
is hard, I want full control over what mechanisms users of my application 
use.  Therefore,  lets insure that no one can possibly produce a 
well-designed modular framework that respects abstraction boundaries, by 
deliberately breaking those boundaries in the specification."

I must say that I do not find that argument even slightly compelling.

-- Jeff