Re: GSS-APIv3 sketch

Nicolas Williams <> Wed, 11 November 2009 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7781E3A6879 for <>; Wed, 11 Nov 2009 12:40:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.026
X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NFgQrf3sTCJ7 for <>; Wed, 11 Nov 2009 12:40:23 -0800 (PST)
Received: from (sca-ea-mail-2.Sun.COM []) by (Postfix) with ESMTP id 776223A684A for <>; Wed, 11 Nov 2009 12:40:23 -0800 (PST)
Received: from ([]) by (8.13.7+Sun/8.12.9) with ESMTP id nABKeZ2R027094 for <>; Wed, 11 Nov 2009 20:40:49 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nABKeZ9F026526 for <>; Wed, 11 Nov 2009 13:40:35 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nABKE1p5013858; Wed, 11 Nov 2009 14:14:01 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nABKE1qc013857; Wed, 11 Nov 2009 14:14:01 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to using -f
Date: Wed, 11 Nov 2009 14:14:01 -0600
From: Nicolas Williams <>
To: Jeffrey Hutzelman <>
Subject: Re: GSS-APIv3 sketch
Message-ID: <20091111201400.GP1105@Sun.COM>
References: <20091111181140.GC10501@Sun.COM> <> <20091111184244.GN1105@Sun.COM> <> <23095_1257966878_nABJEb0J026813_20091111185529.GO1105@Sun.COM> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.7i
Cc:, Love Hörnquist Åstrand <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Nov 2009 20:40:24 -0000

On Wed, Nov 11, 2009 at 02:41:27PM -0500, Jeffrey Hutzelman wrote:
> --On Wednesday, November 11, 2009 12:55:29 PM -0600 Nicolas Williams 
> <> wrote:
> >>>> Well-defined SPI will force everything to reimplemnent GSS-API
> >>>> semantics in all layer, this sucks and duplicates code.
> >>>
> >>> No, see the compat shims.
> >>
> >>That doesn't answer my question, making the SPI look like the API is the
> >>problem.
> >
> >Actually, I have options to set the SPI symbol prefix to anything you
> >like, so as long as you don't have additional SPI arguments (as we do in
> >OpenSolaris) you're OK.  But ALSO, I did answer your question: providers
> >that don't support he new SPI can be accessed via v2u1 mechglues used
> >through the v3 mechglue (that's what the note about shims was about).
> I think you're missing Love's point.  Regardless of what the symbol names 
> are, if the API and SPI are the same, then both the mechglue and each 
> mechanism have to implement all of the semantics of that interface.  That 
> was sort of necessary with GSSAPIv2, because the mechglue concept was 
> introduced after the original API design, which envisioned selecting a 
> mechanism at link time.  Now that we understand how silly that is, there's 
> no reason to presume that anyone will link to a GSSAPIv3 mechanism provider 
> directly, and so the API and SPI need not be the same.

I didn't say the SPI is exactly the same as the API.  I said "mostly".

The reason for the two to be mostly the same is simple: I can't think of
why I'd want the SPI to be radically different than the API, that is, I
haven't found an implementation reason for wanting the SPI to be
radically different than the API.

In fact, having them be at least very similar helps make the code
generation approach possible.  For example, suppose I created a single
SPI function interface to all per-message token functions -- I sure
could, but then the code generator would have to learn all the specific
details of how to map per-msg token API functions onto that one SPI
function, thus negating the whole point of a code generator approach.

Let's look at possible SPI departures from the API:

 - symbol prefixes -- easy to handle
 - extra arguments, as in the OpenSolaris SPI (which is not open)
    - I don't see a need for such extra arguments, but as long as the
      pattern is regular, it can be easily handled
 - instead of using dlopen()/dlsym() you call a function that returns a
   struct full of function pointers -- easy to handle
    - I also forgot to mention that the mechglue configuration interface
      allows you do implement statically-linked providers if you want

 - radical departures from the API, such as merging API functions at the
   SPI layer -- NOT easy to handle

 - gratuitous departures, such as different argument ordering -- why

 - other departures??