[ldapext] empty-groupOfNames-issue

Michael Ströder <michael@stroeder.com> Fri, 04 December 2015 11:17 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 8461B1B3029 for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 03:17:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nGM-Y1zSLNmQ for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 03:17:56 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70421B3025 for <ldapext@ietf.org>; Fri, 4 Dec 2015 03:17:55 -0800 (PST)
Received: from srv4.stroeder.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 56F9D1CF66 for <ldapext@ietf.org>; Fri, 4 Dec 2015 11:17:52 +0000 (UTC)
Received: from nb2.stroeder.local (nb2.stroeder.local []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 79F9B1D29F for <ldapext@ietf.org>; Fri, 4 Dec 2015 11:17:49 +0000 (UTC)
To: ldapext <ldapext@ietf.org>
From: Michael Ströder <michael@stroeder.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <5661765D.6040603@stroeder.com>
Date: Fri, 04 Dec 2015 12:17:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020409020300050803080500"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/xFV_f_rsi2NEmygGiLD_PAiZ-fQ>
Subject: [ldapext] empty-groupOfNames-issue
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 04 Dec 2015 11:17:58 -0000


I try to summarize the pros and cons of approaches dealing with the
empty-groupOfNames-issue raised here and there very often.

Let us please focus on this particular issue.


1. Modified standard schema descriptions for 'groupOfNames' and

This is the work-around already chosen by various vendors:
The MUST member or MUST uniqueMember is turned into MAY.

+ it just works, no interop-problems seen so far.
+ no change required in LDAP clients
+ no change required in access control rules
+ no change required in other client or server-side code dealing with groups

- It violates standardization best practices, most notably IANA considerations.
- It could serve as a bad example to change standard schema at will.

Hopefully Rolf Sonneveld and Andrew Findlay will clearly comment on IANA


2. new object class 'groupOfEntries'

Andrew kindly wrote an mini I-D defining a new structural object class
'groupOfEntries' simply with MAY member instead of MUST meant as direct
replacement for 'groupOfNames'.


+ Very simple
+ Fully compliant to standardization best practices

- It's not clear whether it was widely adopted in deployments.
- small change required in LDAP clients for searching group entries
- small change required in access control rules
- small changes required in other client or server-side code dealing with groups


3. draft-brooks-ldap-sets

More general approach for solving all kinds of grouping issues by providing a
generic schema for sets.


+ generic solution for everything

- completely new approach not compatible at all to what clients expect today
- access control rules have to be modified (which might also be a pro but not sure)
- I-D did not receive much review so far, review effort needed


Add more variants if you know about them.

I'd like to get some result soon on which of these solutions have a vague chance
to be adopted at all.  Given the former discussions we likely achieve a quicker
result if we simply rule out approaches first.

Especially some vendors should raise their voice which approaches they are
willing to adopt or not.

Ciao, Michael.