Re: [ldapext] empty-groupOfNames-issue

Andrew Findlay <andrew.findlay@skills-1st.co.uk> Fri, 04 December 2015 13:53 UTC

Return-Path: <andrew.findlay@skills-1st.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 0040D1B31B9 for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 05:53:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 4YHCLzZWk_5s for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 05:53:01 -0800 (PST)
Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238D41B31B4 for <ldapext@ietf.org>; Fri, 4 Dec 2015 05:53:01 -0800 (PST)
Received: from 208.51.155.90.in-addr.arpa ([90.155.51.208] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1a4qnC-0005Kb-OP; Fri, 04 Dec 2015 13:52:58 +0000
Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1a4qiL-0002TU-7u; Fri, 04 Dec 2015 13:47:57 +0000
Date: Fri, 4 Dec 2015 13:47:57 +0000
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Message-ID: <20151204134757.GE3643@slab.skills-1st.co.uk>
References: <5661765D.6040603@stroeder.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5661765D.6040603@stroeder.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/o8tBKvrebOFlHA8XgZezum_0G3c>
Cc: ldapext <ldapext@ietf.org>
Subject: Re: [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 13:53:03 -0000

On Fri, Dec 04, 2015 at 12:17:49PM +0100, Michael Ströder wrote:

> 1. Modified standard schema descriptions for 'groupOfNames' and
> 'groupOfUniqueNames':
> 
> 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
> considerations.

I don't think there is an IANA consideration here. The modified schema
is (currently) incorrect according to RFC4519 or is alternatively an
experiment leading to a proposed change to a standard. In the latter
case it would have to be accepted by IETF and published in a new RFC
that obsoletes 4519. At that time, IANA would update the reference in
the Object Identifiers table to point to the new document but would have
no other involvement.

In practice I cannot see such a change ever being accepted into the
standards track. If anything, the relatively wide distribution of
non-conformant implementations makes a stronger case for deprecating
these objectclasses for new deployments.

The definition of groupOfNames goes right back to X.521(1988) and it was
already broken at that point:

a)	member was a mandatory attribute

b)	Nested groups were mentioned in the text but the semantics
	were left undefined

> -------------------------------------------------------------------------
> 
> 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'.
> 
> http://tools.ietf.org/html/draft-findlay-ldap-groupofentries
> 
> + Very simple
> + Fully compliant to standardization best practices
> 
> - It's not clear whether it was widely adopted in deployments.

Maybe not in the exact form I described in that I-D, but functionally
equivalent objectclasses have been in most of my customers' systems.
It could be argued that the corrupted form of groupOfNames described
above is actually proof of widespread deployment of an analogous class.

> - 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

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------