Re: comments draft-ietf-kitten-gssapi-naming-exts-05.txt

Leif Johansson <leifj@sunet.se> Mon, 14 September 2009 07:42 UTC

Return-Path: <leifj@sunet.se>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F2C3A69D0 for <kitten@core3.amsl.com>; Mon, 14 Sep 2009 00:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.17
X-Spam-Level:
X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf6KMCB-6H-W for <kitten@core3.amsl.com>; Mon, 14 Sep 2009 00:42:31 -0700 (PDT)
Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 8591F28C12B for <kitten@ietf.org>; Mon, 14 Sep 2009 00:42:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 1DB0B3C5BD; Mon, 14 Sep 2009 09:43:15 +0200 (CEST)
Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27169-01-68; Mon, 14 Sep 2009 09:43:14 +0200 (CEST)
Received: from klapautius.localnet (norducph-gw.nordu.net [193.10.254.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id B15D43C57F; Mon, 14 Sep 2009 09:43:14 +0200 (CEST)
From: Leif Johansson <leifj@sunet.se>
Organization: SUNET
To: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: comments draft-ietf-kitten-gssapi-naming-exts-05.txt
Date: Mon, 14 Sep 2009 09:43:16 +0200
User-Agent: KMail/1.11.2 (Linux/2.6.28-15-generic; KDE/4.2.2; i686; ; )
References: <F081C0B9-4A2C-41EF-9CAE-3BDE8323D94E@kth.se> <20090914051124.GY1033@Sun.COM>
In-Reply-To: <20090914051124.GY1033@Sun.COM>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200909140943.16921.leifj@sunet.se>
X-Virus-Scanned: by amavisd-new at smtp.su.se
Cc: kitten@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2009 07:42:32 -0000

On Monday 14 September 2009 07.11.24 Nicolas Williams wrote:
> On Sun, Sep 13, 2009 at 12:41:08PM -0700, Love Hörnquist Åstrand wrote:

First of all: thanks for the review which you obviously did!

> > name_is_MN is an output variable, the c-bindings define it as an "int"
> > which provides little chance of "out-ness"
>
> A typo.  Thanks.
>
> > I really dislike the modifying name attributes, why is that interface
> > needed (usecase ?)
>
> It's not about modifying names but about making assertions (or asking
> that an authority vouch for them).  You first import a name, then set
> the name attributes corresponding to the assertions you wish to make,
> then you acquire a credential, then you use the credential.
>
> > The *more trick sucks but I can live with it, it assumes names do no
>
> We can always add more set types.  I'm not fond of the idea of adding
> set types, but now that gss_buffer_set_t seems to be here to stay, I
> think I'd give in.

gss_buffer_set_t it is then unless people scream bloody murder at it
fairly soon

>
> > change and that items are iteratable, it also makes mech glue life hard.
>
> Can you explain the last part?  The *more thing is not thread-safe,
> that's for sure (though it fails in safe ways).
>
> > GSS_Map_name_to_any, the type should be an OID, strings are not used
> > anywhere else and its painful to use, its if really a strings, make it
> > a "const char *" in the c bindings.
>
> I'd be happy with a const char *.  I'd also be happy dropping this API.
> (I'd rather OSes have APIs like our gsscred_name_to_unix_cred, where the
> compiler can check types, than that we defeat type checking.)
>

I've never been comfortable with this API - it feels difficult to specify 
property. I'd be in favor of dropping it.

> > same goes for gss_get_name_attribute()
>
> What same?

+1

>
> > Most functions does not talk about memory management, is buffers
> > released or not ?
>
> All buffers must be released.

I guess it doesn't hurt for us to say so explicitly though.

	Chers Leif