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

Leif Johansson <leifj@mnt.se> Mon, 14 September 2009 08:03 UTC

Return-Path: <leifj@mnt.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 E3EE63A6866 for <kitten@core3.amsl.com>; Mon, 14 Sep 2009 01:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 iDnBmw-UdIKA for <kitten@core3.amsl.com>; Mon, 14 Sep 2009 01:03:59 -0700 (PDT)
Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id BCF123A67B8 for <kitten@ietf.org>; Mon, 14 Sep 2009 01:03:58 -0700 (PDT)
Received: by fxm17 with SMTP id 17so654263fxm.37 for <kitten@ietf.org>; Mon, 14 Sep 2009 01:04:39 -0700 (PDT)
Received: by 10.204.21.4 with SMTP id h4mr4864913bkb.58.1252915478696; Mon, 14 Sep 2009 01:04:38 -0700 (PDT)
Received: from klapautius.localnet (norducph-gw.nordu.net [193.10.254.194]) by mx.google.com with ESMTPS id c28sm512374fka.44.2009.09.14.01.04.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Sep 2009 01:04:38 -0700 (PDT)
To: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: comments draft-ietf-kitten-gssapi-naming-exts-05.txt
Content-Disposition: inline
From: Leif Johansson <leifj@mnt.se>
Organization: mnt.se
Date: Mon, 14 Sep 2009 10:04:39 +0200
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <200909141004.39686.leifj@mnt.se>
Cc: kitten@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: leifj@mnt.se
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 08:04:00 -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