Re: [ldapext] DBIS - new IETF drafts

Mark R Bannister <dbis@proseconsulting.co.uk> Wed, 08 January 2014 21:26 UTC

Return-Path: <dbis@proseconsulting.co.uk>
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 271051A1F7A for <ldapext@ietfa.amsl.com>; Wed, 8 Jan 2014 13:26:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 P7UnpZULSZvc for <ldapext@ietfa.amsl.com>; Wed, 8 Jan 2014 13:26:02 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 424171A1F1A for <ldapext@ietf.org>; Wed, 8 Jan 2014 13:26:02 -0800 (PST)
Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1W10dM-0005ip-KO; Wed, 08 Jan 2014 21:25:52 +0000
Message-ID: <52CDC249.8050407@proseconsulting.co.uk>
Date: Wed, 08 Jan 2014 21:25:29 +0000
From: Mark R Bannister <dbis@proseconsulting.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>, ldapext@ietf.org
References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com>
In-Reply-To: <52CD9F94.2090707@stroeder.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
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 21:26:03 -0000

On 08/01/2014 18:57, Michael Ströder wrote:
> 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.
>

Hi Michael,

Please will you give me a more solid example of what you are referring 
to re access control?  What is it exactly you think you'd like to do 
with regards to group membership and server-side access control?

Thanks,
Mark.