From michael@stroeder.com Fri Jul 1 09:13:32 2011 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5671F0C69 for ; Fri, 1 Jul 2011 09:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSmco5C0nh8s for ; Fri, 1 Jul 2011 09:13:30 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 74F4F1F0C64 for ; Fri, 1 Jul 2011 09:13:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 6C9C34E119; Fri, 1 Jul 2011 18:13:21 +0200 (CEST) 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 6opnVq7bz7u8; Fri, 1 Jul 2011 18:13:19 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id F32584E10F; Fri, 1 Jul 2011 18:13:18 +0200 (CEST) Message-ID: <4E0DF21D.8060709@stroeder.com> Date: Fri, 01 Jul 2011 18:13:17 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1 MIME-Version: 1.0 To: "Kurt D. Zeilenga" References: <7.0.1.0.0.20060619225054.022df6e8@OpenLDAP.org> <4497ADCB.50902@stroeder.com> <7.0.1.0.0.20060620075240.022dfba8@OpenLDAP.org> <48569DB6.3040402@stroeder.com> In-Reply-To: <48569DB6.3040402@stroeder.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: ldapext@ietf.org Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-relax-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 16:13:32 -0000 Kurt, Michael Ströder wrote: > Kurt D. Zeilenga wrote: >> At 01:11 AM 6/20/2006, Michael Ströder wrote: >>> Kurt D. Zeilenga wrote: >>>> This I-D replaces draft-zeilenga-ldap-managedit-00... >>> Any changes in protocol besides the editorial modifications? >> >> I included 'entryDN' in the list of attributes whose >> NO-USER-MODIFICATION constraint cannot be relaxed. > > The draft seems to be expired. What does it need to be re-submitted? http://tools.ietf.org/html/draft-zeilenga-ldap-relax-03 is expired since end of 2008 but some software already uses this feature. The control's OID is still not assigned (OpenLDAP's exp. OID arc). What is needed to get this approved at least as informational RFC? I'd also suggest that relaxable attribute types are announced with X-RELAX in the subschema subentry so that a schema-aware client can determine which attributes to make editable in case the control is in effect. Ciao, Michael. From michael@stroeder.com Fri Jul 1 11:16:39 2011 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA0C11E808A for ; Fri, 1 Jul 2011 11:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RUBlt4gVP8M for ; Fri, 1 Jul 2011 11:16:38 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id C42B511E8100 for ; Fri, 1 Jul 2011 11:16:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 419104E126; Fri, 1 Jul 2011 20:16:25 +0200 (CEST) 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 OFm8IDgGddWE; Fri, 1 Jul 2011 20:16:23 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id DBAFB4E123; Fri, 1 Jul 2011 20:16:22 +0200 (CEST) Message-ID: <4E0E0EF6.9010708@stroeder.com> Date: Fri, 01 Jul 2011 20:16:22 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1 MIME-Version: 1.0 To: Kurt Zeilenga References: <7.0.1.0.0.20060619225054.022df6e8@OpenLDAP.org> <4497ADCB.50902@stroeder.com> <7.0.1.0.0.20060620075240.022dfba8@OpenLDAP.org> <48569DB6.3040402@stroeder.com> <4E0DF21D.8060709@stroeder.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-relax-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 18:16:39 -0000 Kurt Zeilenga wrote: > On Jul 1, 2011, at 9:13 AM, Michael Ströder wrote: >> I'd also suggest that relaxable attribute types are announced with X-RELAX in >> the subschema subentry so that a schema-aware client can determine which >> attributes to make editable in case the control is in effect. > > I rather not get into detail advertisement of what DSAs will or will not > relax when this control is used. This is a problem that not easily > solved. > > It's basically assumed that this control will be used by the DSA > administrator who as knowledge of what will get relaxed when it's used. What problems are not easily solved? The behaviour of web2ldap's UI already changes if this control is in effect. E.g. input fields of relaxable attributes are enabled if the user turns on the relax rules control. Obviously I'd prefer to look at the subschema to find out which attributes can be relaxed instead of maintaining a hard-coded list in web2ldap's code. > It's not intended to be used generally. Yes, the control is for the expert DSA admin. But a good admin tool guides the admin user too. ;-) > I see that some implementations rely use of this relax control by users who > might no be theDSA administrators to overcome poor design of certain > LDAP/X.500 "policy" extensions. Such use is beyond the scope of this > extension. I would rather see better designs in these policy extensions. Yes, so please comment in detail on the mailing lists where you saw this. ;-) Ciao, Michael. From andrew.findlay@skills-1st.co.uk Fri Jul 1 11:26:40 2011 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C1E11E8091 for ; Fri, 1 Jul 2011 11:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkUOW1o0n0uI for ; Fri, 1 Jul 2011 11:26:39 -0700 (PDT) Received: from gnu.ourshack.com (gnu.ourshack.com [84.45.68.121]) by ietfa.amsl.com (Postfix) with ESMTP id CEFEF11E811A for ; Fri, 1 Jul 2011 11:26:33 -0700 (PDT) Received: from [2a01:348:28c:1:221:6aff:fe6d:90b2] (helo=slab.skills-1st.co.uk) by gnu.ourshack.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QciN5-0004kR-7C; Fri, 01 Jul 2011 19:23:19 +0100 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.74) (envelope-from ) id 1QciN4-0005jP-PO; Fri, 01 Jul 2011 19:23:18 +0100 Date: Fri, 1 Jul 2011 19:23:18 +0100 From: Andrew Findlay To: Michael =?iso-8859-1?Q?Str=F6der?= Message-ID: <20110701182318.GY21842@slab.skills-1st.co.uk> References: <7.0.1.0.0.20060619225054.022df6e8@OpenLDAP.org> <4497ADCB.50902@stroeder.com> <7.0.1.0.0.20060620075240.022dfba8@OpenLDAP.org> <48569DB6.3040402@stroeder.com> <4E0DF21D.8060709@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4E0DF21D.8060709@stroeder.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: ldapext@ietf.org, "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-relax-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 18:26:40 -0000 On Fri, Jul 01, 2011 at 06:13:17PM +0200, Michael Ströder wrote: > http://tools.ietf.org/html/draft-zeilenga-ldap-relax-03 is expired since end > of 2008 but some software already uses this feature. The control's OID is > still not assigned (OpenLDAP's exp. OID arc). > I'd also suggest that relaxable attribute types are announced with X-RELAX in > the subschema subentry so that a schema-aware client can determine which > attributes to make editable in case the control is in effect. I would certainly support some such mechanism. At present the only way to find out what is relaxable is to test the operation. Also, section 3.6 requires that operational attributes may not be relaxed unless there is a document permitting that action. The draft itself mentions some common attributes, but omits (for exapmle) all the attributes described in draft-behera-ldap-password-policy, where this control is essential for user management if the policy schema is taken at face value. As the password policy is still in draft, it would seem appropriate to update both drafts and submit them together. draft-behera is so widely used in practice that it really should be at least an Informational RFC. 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 | ----------------------------------------------------------------------- From Kurt.Zeilenga@Isode.COM Fri Jul 1 11:28:15 2011 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCFA11E8091 for ; Fri, 1 Jul 2011 11:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITuwKiV9M07v for ; Fri, 1 Jul 2011 11:28:13 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28A11E808A for ; Fri, 1 Jul 2011 11:28:13 -0700 (PDT) Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 1 Jul 2011 19:28:12 +0100 From: Kurt Zeilenga In-Reply-To: <4E0DF21D.8060709@stroeder.com> Date: Fri, 1 Jul 2011 11:28:08 -0700 Message-Id: <58D4405F-1BD0-4224-A46B-C035B6F2E6D0@Isode.COM> References: <7.0.1.0.0.20060619225054.022df6e8@OpenLDAP.org> <4497ADCB.50902@stroeder.com> <7.0.1.0.0.20060620075240.022dfba8@OpenLDAP.org> <48569DB6.3040402@stroeder.com> <4E0DF21D.8060709@stroeder.com> To: =?iso-8859-1?Q?Michael_Str=F6der?= X-Mailer: Apple Mail (2.1242) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-relax-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 18:28:15 -0000 [Resend from subscribed address] On Jul 1, 2011, at 9:13 AM, Michael Str=F6der wrote: > Kurt, >=20 > Michael Str=F6der wrote: >> Kurt D. Zeilenga wrote: >>> At 01:11 AM 6/20/2006, Michael Str=F6der wrote: >>>> Kurt D. Zeilenga wrote: >>>>> This I-D replaces draft-zeilenga-ldap-managedit-00... >>>> Any changes in protocol besides the editorial modifications? >>>=20 >>> I included 'entryDN' in the list of attributes whose >>> NO-USER-MODIFICATION constraint cannot be relaxed. >>=20 >> The draft seems to be expired. What does it need to be re-submitted? >=20 > http://tools.ietf.org/html/draft-zeilenga-ldap-relax-03 is expired = since end > of 2008 but some software already uses this feature. The control's = OID is > still not assigned (OpenLDAP's exp. OID arc). Purposely. As a matter of practice, I don't provide OIDs to = works-in-progress. I prefer the OID to be assigned just prior to = publication as an RFC so that one can distinguish between = implementations of the RFC and earlier implementations, which might = differ significantly (more than by which OID is used). > What is needed to get this approved at least as informational RFC? I think Experimental is better for this than Informational. Outside of = IETF circles, the difference is not terribly significant.=20 > I'd also suggest that relaxable attribute types are announced with = X-RELAX in > the subschema subentry so that a schema-aware client can determine = which > attributes to make editable in case the control is in effect. I rather not get into detail advertisement of what DSAs will or will not = relax when this control is used. This is a problem that not easily = solved. It's basically assumed that this control will be used by the DSA = administrator who as knowledge of what will get relaxed when it's used. = It's not intended to be used generally. I see that some implementations rely use of this relax control by users = who might no be theDSA administrators to overcome poor design of certain = LDAP/X.500 "policy" extensions. Such use is beyond the scope of this = extension. I would rather see better designs in these policy = extensions. -- Kurt >=20 > Ciao, Michael. > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From Kurt.Zeilenga@Isode.COM Fri Jul 1 12:33:57 2011 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7F79E800B for ; Fri, 1 Jul 2011 12:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaLtZZo07HQv for ; Fri, 1 Jul 2011 12:33:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 990189E8008 for ; Fri, 1 Jul 2011 12:33:56 -0700 (PDT) Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 1 Jul 2011 20:33:55 +0100 From: Kurt Zeilenga In-Reply-To: <4E0E0EF6.9010708@stroeder.com> Date: Fri, 1 Jul 2011 12:33:52 -0700 Message-Id: <04804C37-D1C3-4034-BCA5-325533D0938D@Isode.COM> References: <7.0.1.0.0.20060619225054.022df6e8@OpenLDAP.org> <4497ADCB.50902@stroeder.com> <7.0.1.0.0.20060620075240.022dfba8@OpenLDAP.org> <48569DB6.3040402@stroeder.com> <4E0DF21D.8060709@stroeder.com> <4E0E0EF6.9010708@stroeder.com> To: =?iso-8859-1?Q?Michael_Str=F6der?= X-Mailer: Apple Mail (2.1242) MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-relax-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 19:33:57 -0000 On Jul 1, 2011, at 11:16 AM, Michael Str=F6der wrote: > Kurt Zeilenga wrote: >> On Jul 1, 2011, at 9:13 AM, Michael Str=F6der wrote: >>> I'd also suggest that relaxable attribute types are announced with = X-RELAX in >>> the subschema subentry so that a schema-aware client can determine = which >>> attributes to make editable in case the control is in effect. >>=20 >> I rather not get into detail advertisement of what DSAs will or will = not >> relax when this control is used. This is a problem that not easily >> solved. >>=20 >> It's basically assumed that this control will be used by the DSA >> administrator who as knowledge of what will get relaxed when it's = used. >=20 > What problems are not easily solved? It seems to me you want to use schema to determine whether or not a DSA, = not necessarily the master DSA for the target object, implements = relaxation of some constraint associated with some element of schema. = And you want to use subschema for this. This I see as quite problematic. First, there's the problem of what exactly does it mean for something to = be published in a subschema. The assumptions a client (or server) can = make based upon something being published in a subschema is quite = limited. For instance, consider the case where a master DSA for a particular = context provides a schema description for a DSA-specific operational = attribute. What do we expect shadow and caching DSAs to do in this = case? If they don't implement the DSA-specific operational attribute, = are they to remove it from the subschema when they publish it? Are they = to modify it based upon their relax capabilities? Are they to add = DSA-specific operational attributes descriptions to the subschema for = which they support but the master doesn't provide in the subschema? = (Note: while LDAP allows for use of non-X.500 subentry models, it's = written in terms of the X.500 models. Extensions should generally be = written likewise.) Even if we were to assume a DSA-specific schema model, such as common in = today's LDAP-only directory servers, what are DSAs to do when the = constraint is relaxable in certain cases but not others, such as which = entry is the target. And what if the schema elements has multiple constraints which possibly = could be relaxed, how do you distinguish precisely which constraints can = be relaxed? For instance, does X-RELAX on objectClass merely mean that = object metamorphism is supported, or does it also mean that constraint = on adding obsolete classes is relaxed? Is the server to list X-RELAX = if any constraint can be relaxed? or is needed to indicate precisely = which constraint can be relaxed? Precision is problematic as I intended the use cases only as examples of = constraints would could be relaxed by this control. What about advertising authorization specific relaxation availability? Also note that X- use in RFCs is problematic. RFC 4512 says: Implementors should note that future versions of this document may expand these definitions to include additional terms. Terms whose identifier begins with "X-" are reserved for private experiments and are followed by and tokens. as anything published as an RFC is not a "private experiment" by = definition. There was discussion back in LDAPbis days, IIRC, about why adding = non-X-* terms to the schema definitions is a bad idea. IIRC, that = discussion was part of the BCP 64 (RFC 4520) discussion. Please note = that adding a non-X-* term today would require updating of either RFC = 4512 or RFC 4520=85 and that's more than I want to chew off. > The behaviour of web2ldap's UI already changes if this control is in = effect. How does web2ldap determine whether or not this control can only be used = in conduction with another control, say the authzid control (to assert a = role identity)? (rhetorical question) Obviously there are significant limitations of what schema discovery can = reasonably provide. > E.g. input fields of relaxable attributes are enabled if the user = turns on the > relax rules control. Obviously I'd prefer to look at the subschema to = find out > which attributes can be relaxed instead of maintaining a hard-coded = list in > web2ldap's code. It was my intent that this control only be used at the explicit request = of the directory administrator. Hence, I never consider detailed = discover as within scope of the I-D. >> It's not intended to be used generally. >=20 > Yes, the control is for the expert DSA admin. Yes, but only when specifically requested. > But a good admin tool guides the admin user too. ;-) Consider, for instance, an admin using a tool wants to change the = entryUUID of an entry. I would think a good admin tool could detect that the operation the = admin user proposes is counter to various constraints, and then ask the = admin if they would like to try the operation anyways (without the relax = control) or would they like to include the relax control. Likewise if the user wants to change a device into a person. I don't think any admin tool should use this control without the = explicit approval of the user. This because the control side-steps the = directory models, and doing that can have side-effects bound that which = any reasonable tool could possibly understand. >> I see that some implementations rely use of this relax control by = users who >> might no be theDSA administrators to overcome poor design of certain >> LDAP/X.500 "policy" extensions. Such use is beyond the scope of = this >> extension. I would rather see better designs in these policy = extensions. >=20 > Yes, so please comment in detail on the mailing lists where you saw = this. ;-) The most common abuse of this control is to overcome the poor design of = various password policy extensions. See my prior rants on this and = other LDAP lists about various password policy extensions. Beyond that, = I won't comment about them in this thread as that would be highly = disruptive to discussions directly concerning this I-D. >=20 > Ciao, Michael. > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From michael@stroeder.com Mon Jul 4 11:21:43 2011 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6847E1F0C35 for ; Mon, 4 Jul 2011 11:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42JhbgtRsAsC for ; Mon, 4 Jul 2011 11:21:43 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id AF0481F0C34 for ; Mon, 4 Jul 2011 11:21:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 90D554E0C5; Mon, 4 Jul 2011 20:21:38 +0200 (CEST) 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 PShVkpyWZZBt; Mon, 4 Jul 2011 20:21:36 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id D649C4E0F2; Mon, 4 Jul 2011 20:21:35 +0200 (CEST) Message-ID: <4E11702A.9070009@stroeder.com> Date: Mon, 04 Jul 2011 09:47:54 +0200 From: =?windows-1252?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1 MIME-Version: 1.0 To: Kurt Zeilenga References: <7.0.1.0.0.20060619225054.022df6e8@OpenLDAP.org> <4497ADCB.50902@stroeder.com> <7.0.1.0.0.20060620075240.022dfba8@OpenLDAP.org> <48569DB6.3040402@stroeder.com> <4E0DF21D.8060709@stroeder.com> <4E0E0EF6.9010708@stroeder.com> <04804C37-D1C3-4034-BCA5-325533D0938D@Isode.COM> In-Reply-To: <04804C37-D1C3-4034-BCA5-325533D0938D@Isode.COM> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-relax-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 18:21:43 -0000 Kurt Zeilenga wrote: > It seems to me you want to use schema to determine whether or not a DSA, > not necessarily the master DSA for the target object, implements relaxation > of some constraint associated with some element of schema. And you want to > use subschema for this. > > This I see as quite problematic. > > First, there's the problem of what exactly does it mean for something to be > published in a subschema. The assumptions a client (or server) can make > based upon something being published in a subschema is quite limited. To stay out of nit-picking my suggestion for a definition would be: If there's a standard document saying that the Relax Rules Control MAY be used to add/modify the attribute the attribute type description SHOULD contain option X-RELAX. All the issues you wrote apply to other subschema elements anyway and web2ldap contains a lot of fall back behaviour. Also note that web2ldap does not automagically enable use of this control. It's still up to the admin user to enable it manually - kind of a special mode. But if in this mode I'd like to know which input fields to enable. I don't know how to get out of the X- prefix issue and RFCs. But I'd consider it very bad if LDAPv3 does not allow any extension of the schema descriptions with additional options usable in a newer RFC. Ciao, Michael. From masarati@aero.polimi.it Mon Jul 4 13:48:20 2011 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E8911E80AB for ; Mon, 4 Jul 2011 13:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE5LsvGeKIld for ; Mon, 4 Jul 2011 13:48:19 -0700 (PDT) Received: from spmsrv.aero.polimi.it (spmsrv.aero.polimi.it [131.175.154.192]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEA111E8094 for ; Mon, 4 Jul 2011 13:48:18 -0700 (PDT) Received: from spmsrv.aero.polimi.it (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3389891C082; Mon, 4 Jul 2011 22:48:16 +0200 (CEST) Received: from www.aero.polimi.it (www.aero.polimi.it [131.175.154.199]) by spmsrv.aero.polimi.it (Postfix) with ESMTP id 6B61E91C080; Mon, 4 Jul 2011 22:48:11 +0200 (CEST) Received: from 195.244.169.41 (SquirrelMail authenticated user masarati) by www.aero.polimi.it with HTTP; Mon, 4 Jul 2011 22:48:11 +0200 (CEST) Message-ID: In-Reply-To: <4E11702A.9070009@stroeder.com> References: <7.0.1.0.0.20060619225054.022df6e8@OpenLDAP.org> <4497ADCB.50902@stroeder.com> <7.0.1.0.0.20060620075240.022dfba8@OpenLDAP.org> <48569DB6.3040402@stroeder.com> <4E0DF21D.8060709@stroeder.com> <4E0E0EF6.9010708@stroeder.com> <04804C37-D1C3-4034-BCA5-325533D0938D@Isode.COM> <4E11702A.9070009@stroeder.com> Date: Mon, 4 Jul 2011 22:48:11 +0200 (CEST) From: masarati@aero.polimi.it To: Michael =?iso-8859-15?Q?Str=F6der?= User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.7.4.203616 X-PMX-Spam: Gauge=XI, Probability=11%, Report=' PRIORITY_NO_NAME 0.716, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1800_1899 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, NO_REAL_NAME 0, NO_URI_FOUND 0, WEBMAIL_SOURCE 0, WEBMAIL_USER_AGENT 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __SANE_MSGID 0, __SXL_URI_TIMEOUT , __TO_MALFORMED_2 0, __USER_AGENT 0' Cc: ldapext@ietf.org, Kurt Zeilenga Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-relax-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 20:48:20 -0000 > Kurt Zeilenga wrote: >> It seems to me you want to use schema to determine whether or not a DSA, >> not necessarily the master DSA for the target object, implements >> relaxation >> of some constraint associated with some element of schema. And you want >> to >> use subschema for this. >> >> This I see as quite problematic. >> >> First, there's the problem of what exactly does it mean for something to >> be >> published in a subschema. The assumptions a client (or server) can make >> based upon something being published in a subschema is quite limited. > > To stay out of nit-picking my suggestion for a definition would be: > If there's a standard document saying that the Relax Rules Control MAY be > used > to add/modify the attribute the attribute type description SHOULD contain > option X-RELAX. > > All the issues you wrote apply to other subschema elements anyway and > web2ldap > contains a lot of fall back behaviour. > > Also note that web2ldap does not automagically enable use of this control. > It's still up to the admin user to enable it manually - kind of a special > mode. But if in this mode I'd like to know which input fields to enable. > > I don't know how to get out of the X- prefix issue and RFCs. But I'd > consider > it very bad if LDAPv3 does not allow any extension of the schema > descriptions > with additional options usable in a newer RFC. What about stating that attributeTypes MAY have a X-RELAX (please note that it needs to have a value, so X-RELAX 'TRUE' may be needed) option if that attribute MAY be modified using the relax control? The double conditional would "relax" the use of this private, and thus non-publicable, extension. Hope I made the point, I wouldn't be able to formalize it further right now, as I just made too direct an acquaintance with Belgian beer :) Cheers from Brussels, p. From Kurt.Zeilenga@Isode.COM Mon Jul 4 19:19:01 2011 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2646B21F875B for ; Mon, 4 Jul 2011 19:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsEHVXVzzB2F for ; Mon, 4 Jul 2011 19:19:00 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 674F121F856A for ; Mon, 4 Jul 2011 19:19:00 -0700 (PDT) Received: from [192.168.42.8] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 5 Jul 2011 03:18:59 +0100 From: Kurt Zeilenga In-Reply-To: <4E11702A.9070009@stroeder.com> Date: Mon, 4 Jul 2011 19:18:55 -0700 Message-Id: <250DBE75-6060-4485-9376-4BEA82B5CB47@Isode.COM> References: <7.0.1.0.0.20060619225054.022df6e8@OpenLDAP.org> <4497ADCB.50902@stroeder.com> <7.0.1.0.0.20060620075240.022dfba8@OpenLDAP.org> <48569DB6.3040402@stroeder.com> <4E0DF21D.8060709@stroeder.com> <4E0E0EF6.9010708@stroeder.com> <04804C37-D1C3-4034-BCA5-325533D0938D@Isode.COM> <4E11702A.9070009@stroeder.com> To: =?iso-8859-1?Q?Michael_Str=F6der?= X-Mailer: Apple Mail (2.1244.3) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-relax-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 02:19:01 -0000 On Jul 4, 2011, at 12:47 AM, Michael Str=F6der wrote: > I don't know how to get out of the X- prefix issue and RFCs. Start by drafting an update RFC 4512 which changes extensions =3D *( SP xstring SP qdstrings ) to: extensions =3D *( SP extension SP qdstrings ) extension =3D keystring and updates BCP 64 (RFC 4520) to provide a registry for values of = extension with appropriate registration guidelines, including possibly a = reservation of values starting with "X-" for private extensions (see = apps discussion concerning this practice). > But I'd consider it very bad if LDAPv3 does not allow any extension of = the schema descriptions > with additional options usable in a newer RFC. I note that the X- extension restriction was discussed during the = LDAPbis development of RFC 4512 with, IIRC, there being insufficient = support to make such a change.=20 My view is that relax I-D only describes an experiment. One of the = things that might be learned by this experiment is that more detailed = discovery is needed. If so, the future standards work can take care of = that. My intent, however, is that the relax experiment not be itself = an experiment in how to provide detailed discovery (which might be = something to experiment with before standardizing a facility for = detailed discovery). I'm willing to make a few minor editorial changes to the I-D and then = submitting it to the RFC Editor for publication on the Experimental = track in the Independent Submission. If the consensus of the IETF is, = however, that the IETF rather develop a standard in this area, I have no = objection to the IETF using my I-D as a basis for that work. However, I = seriously doubt the IETF has enough energy in the LDAP arena to do much = LDAP work (as evident by the progress of various LDAP I-Ds), and in = absence of enough energy within the IETF, we continue to encourage = independent advancement in the LDAP space. -- Kurt From michael@stroeder.com Thu Jul 14 10:46:44 2011 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7798C21F8CD5 for ; Thu, 14 Jul 2011 10:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIgElEFFbjPf for ; Thu, 14 Jul 2011 10:46:43 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 4A99E21F8CB8 for ; Thu, 14 Jul 2011 10:46:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 3A5534E0C6; Thu, 14 Jul 2011 19:46:37 +0200 (CEST) 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 ZCFiIrIIKapS; Thu, 14 Jul 2011 19:46:31 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 37A0F4E0B0; Thu, 14 Jul 2011 19:46:29 +0200 (CEST) Message-ID: <4E1F15C5.2000306@stroeder.com> Date: Thu, 14 Jul 2011 18:13:57 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2 MIME-Version: 1.0 To: LDAP Extensions list , PC@lists.ldapcon.org References: <480F49A5.7020703@stroeder.com> <48157B47.9090505@eb2bcom.com> In-Reply-To: <48157B47.9090505@eb2bcom.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [ldapext] extensions for subschema (was: Additional constraints for attribute values in subschema) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 17:46:44 -0000 HI! While this ietf-ldapext thread was back in 2008 it's IMO still something worth to think about. How about discussing this in a BoF session at LDAPcon 2011 in October? Yes, I was too busy to write that up for a submission... Ciao, Michael. Steven Legg wrote: > > Hi Michael, > > Michael Ströder wrote: >> HI! >> >> I'd like to discuss the idea of defining and publishing additional >> constraints on attribute values in the subschema subentry in a standardized >> way so that schema-aware clients can obey these constraints guiding the user >> and servers can enforce these constraints when entries are added or modified. >> >> Please let me know what you think about explanations below. >> >> Ciao, Michael. >> >> ---------------------------------------------------------------------- >> >> Sometimes it's not sufficient to simply specify an existing LDAP syntax >> or SINGLE-VALUE flag for an attribute type to express more specific >> constraints on attribute values. >> >> Such constraints are considered most times to be part of a local directory >> profile defined by the DSA administrator, but it is not limited to this >> purpose. Schema designers MAY also define additional constraints in >> published standards. Also servers MAY enforce constraints not specified like >> explained herein (e.g. a unique value constraint). >> >> There are several possible approaches for this: >> >> 1. Extend attributeTypes in subschema subentry with additional parameters. >> This would require to change standard schema definitions for locally >> profiling a directory which is widely considered bad practice. Also >> compability to older implementations is a risk. > > Another problem is that the underlying ASN.1 type for attributeTypes, > i.e., AttributeTypeDescription, is controlled by the X.500 working group. > If the LDAP-specific encoding is extended but the X.500 definition isn't, > then there is no way to transport the additional parameters in the X.500 > protocols (unless they can be expressed as an ASN.1 constraint). > >> >> 2. Proprietary server-configuration like already implemented in server >> products. The caveat is that an interactive schema-aware client cannot >> retrieve this constraint information in a standardized way. So guiding the >> user to do the right thing is not possible. >> >> 3. A subentry specification for a part of the DIT. Unfortunately this >> mechanism is AFAIK not widely supported in current server implementations >> and needs more work. >> >> 4. My proposal is to add a new attribute 'attributeConstraints' to the >> subschema subentry which associates additional constraints with a certain >> attribute type by OID crossref similar like DIT content rules do for >> structural object classes. > > Approach 4 is the way I would tackle it. > >> >> Possible constraints: >> >> REGEX >> Regular expression defining a valid syntax of attribute values > > Kurt has already made the point the REGEX works better at the level > of ASN.1 abstract values (as opposed to the particular encoding of > the value), and it so happens that ASN.1 has a PATTERN constraint > for applying a regular expression to a character string. It can also > apply constraints to specific components of complex syntaxes, which > would make it easier to target the right part of a structured value. > > A limited subset of ASN.1 constraint notation would be sufficient > to cover the REGEX, VALUES and MAXCHARLEN cases, and would provide > an obvious upgrade path for the future. > >> >> VALUES >> Explicit set of possible attribute values. (The constraint itself could also >> be achieved by REGEX but it enables the client to provide a typical select >> list at the user interface.) >> >> LDAPURI >> LDAP URL specifying a set of possible attribute values as LDAP search >> results. If attrs is not specified the DNs of the found entries are the set >> of possible values. >> >> OPTIONS >> Set of possible tagging attribute options or option tag/range prefixes. >> >> MAXNUMBER >> max. count of multi-valued attribute values >> >> MAXBYTELEN >> maximum numbers of bytes > > The size of a value transferred in protocol depends of the encoding rules > used and even on options used within a set of rules. An LDAP-specific > encoding of a value will usually be a different length to its BER encoding > or GSER encoding. A specification would have to be very clear about how > the length is calculated. Perhaps it's not worth the trouble. > >> >> MAXCHARLEN >> maximum lenght of a character-based string (depending on syntax) >> >> Either one of REGEX, VALUES and LDAPURI SHALL be allowed, not combinations >> of these parameters. > > It don't see any great problem in allowing parameters to at least be combined > by union. A set of values is a union after all. > >> >> Examples (lines partially wrapped in this message): >> >> For constraining attribute type 'o' to a set of 'o' attribute >> values of already existing company entries. (This might cause problems if >> only one subschema subentry is present for the whole DIT.) >> >> attributeConstraints ( 2.5.4.10 >> LDAPURI >> ldap://dir.example.com/ou=Companies,dc=example,dc=com?o?one?(objectClass=organization) >> >> ) > > I'd much rather see the LDAP-specific encoding of any new LDAP syntax defined > to be the GSER encoding with respect to a specified ASN.1 type. It's easier to > support for those of us with GSER decoders, and makes no real difference to > those who hand craft their parsers. I imagine the GSER encoding of an > attributeConstraints value would look something like this: > > { type o, ldapURI > "ldap://dir.example.com/ou=Companies,dc=example,dc=com?o?one? > (objectClass=organization)" } > > Regards, > Steven > >> >> For attribute type 'manager' be chosen from DNs of existing entries: >> >> attributeConstraints ( 0.9.2342.19200300.100.1.10 >> LDAPURI >> ldap://dir.example.com/dc=example,dc=com??sub?(&(objectClass=inetOrgPerson)(title=Manager)) >> >> ) >> >> For attribute type 'jpegPhoto' of restricted size and to a single value >> (overrides multi-valued default): >> >> attributeConstraints ( 0.9.2342.19200300.100.1.60 >> MAXNUMBER 1 >> MAXBYTELEN 4000 >> ) >> >> Restricting a (proprietary) attribute 'gender' to values specified in ISO >> standard 5801: >> >> attributeConstraints ( 1.3.6.1.4.1.5427.1.389.4.7 >> VALUES ( '0' $ '1' $ '2' $ '9' ) >> )