IETF Logo Mail Archive

Re: [ldapext] DBIS - new IETF drafts

Michael Ströder <michael@stroeder.com> Wed, 08 January 2014 20:08 UTC

Return-Path: <michael@stroeder.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1E41AE575 for <ldapext@ietfa.amsl.com>; Wed, 8 Jan 2014 12:08:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.839
X-Spam-Level:
X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2VP9CwgMKl5 for <ldapext@ietfa.amsl.com>; Wed, 8 Jan 2014 12:08:05 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC4F1ADFA6 for <ldapext@ietf.org>; Wed, 8 Jan 2014 12:08:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 8C6F160719 for <ldapext@ietf.org>; Wed, 8 Jan 2014 21:07:54 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geqpGaTfk_8p for <ldapext@ietf.org>; Wed, 8 Jan 2014 21:07:46 +0100 (CET)
Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Str??der", Issuer "CA Cert Signing Authority" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id AD19A60714 for <ldapext@ietf.org>; Wed, 8 Jan 2014 20:07:45 +0000 (UTC)
Message-ID: <52CD9F94.2090707@stroeder.com>
Date: Wed, 08 Jan 2014 19:57:24 +0100
From: Michael Ströder <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
MIME-Version: 1.0
To: ldapext@ietf.org
References: <1389133522.4574.30.camel@sorbet.thuis.net>
In-Reply-To: <1389133522.4574.30.camel@sorbet.thuis.net>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms000806010207010903080700"
Subject: Re: [ldapext] DBIS - new IETF drafts
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 20:08:08 -0000

Arthur de Jong wrote:
> I personally like the use of flat names to describe group membership. It
> makes the semantics much simpler than dealing with things like the
> member or uniqueMember attribute (at least from a client implementation
> perspective).
> 
> The use of distinguished names may seem more logical from an LDAP
> structure point of view, but you will have to dereference any DN to a
> user name for building up a group entry resulting in potentially a lot
> of search operations to get complete data.

Using DNs allows to implement server-side access control. I'm not a friend of
letting client-side demons enforce the access control because if a machine got
hacked the attacker can find out more about the infrastructure.

Ciao, Michael.

v2.23.0 | Report a Bug | By Email