Dieter Klünter | 8 Apr 10:57 2016


the IETF 96 Session will be held on July 17. - 22. in Berlin. Should
this working group meet at Berlin? 



[*] sys4 AG
Tel.: +49 (89) 30 904 664
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Ldapext mailing list
Ldapext <at>
Sean Leonard | 12 Mar 18:23 2016

New Version Notification for draft-seantek-ldap-pkcs9-04.txt

This is a friendly reminder that the LDAP PKCS #9 registration 
Internet-Draft is still a live issue.


-------- Forwarded Message --------
Subject: 	New Version Notification for draft-seantek-ldap-pkcs9-04.txt
Date: 	Sat, 12 Mar 2016 09:20:32 -0800
From: 	internet-drafts <at>

A new version of I-D, draft-seantek-ldap-pkcs9-04.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-ldap-pkcs9
Revision:	04
Title:		Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9
Document date:	2016-03-12
Group:		Individual Submission
Pages:		7

    PKCS #9 includes several useful definitions that are not yet
    reflected in the LDAP IANA registry. This document adds those
    definitions to the IANA registry.
(Continue reading)

Michael Ströder | 13 Jan 14:50 2016

support for Assertion Control


I need to do some interop-testing for a work-around in case an Assertion Control
[1] is sent along with modify requests. I currently only know two LDAP servers
supporting it:

Any other LDAP servers supporting [1] which I should test with?
Do they have attribute 'entryDN' [2] in their entries and support for at least
EQUALITY matching?

Ciao, Michael.


Attachment (smime.p7s): application/pkcs7-signature, 5738 bytes
Ldapext mailing list
Ldapext <at>
Andrew Findlay | 4 Dec 19:00 2015

A more radical approach to 2307

RFC2307, 2307bis and DBIS all start from the NIS/YP/files-in-etc model
and represent the data in LDAP with varying degrees of fidelity.
Is this actually a good idea? I rather think not.

The big value of LDAP and related things in complex organisations is
that it allows a single abstract representation of 'important stuff'
that can be used by many systems. To work in this environment the
systems have to be flexible, with minimal built-in assumptions about the
data. We have already established that no abstract representation can
provide the full generality and semantics of each system's native
database so compromise and simplification is essential.

With this in mind (and donning my best flameproof suit) I suggest a
radical approach to the task in hand:

	Throw out most of the 2307 NIS-like definitions.

	Consider what an Enterprise-level LDAP service might really
	contain *before* any OS-specific or app-specific requirements
	are imposed on it.

	Create new schema if needed to support a clean representation
	of that Enterprise data.

	Create new AUXILIARY classes to support the attributes needed
	for POSIX systems.

The resulting set of attributes and classes would be *much* smaller than
the 2307 set. Some whole categories could just vanish, e.g.:

(Continue reading)

Michael Ströder | 4 Dec 12:17 2015



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'
(Continue reading)

Charlie | 4 Dec 00:12 2015

LDAP Groups topic split-out

After reading David Foster Wallace on set theory, I wrote an RFC a
couple years back to address the lack of a generic or globally useful
grouping mechanism in LDAP-accessible directories.  Comments are

If you're not up for a long-read, I would recommend just reading
"Appendix D:  Other Efforts and their Shortcomings" which explains all
the attempts to date and how they've failed to gain traction.

Projects continue to try to solve their individual problems instead of
working towards a truly generic grouping mechanism that will suit all
needs, so nothing's progressing.  Simo mentioned this in the context
of FreeIPA, for example - they broke their implementation of RFC2307
and moved on, rather than helping Andrew Findlay create a standard
that supported empty groups.  It seems like each of us is focused on
our own potato patch.

Michael Ströder | 1 Dec 19:29 2015

NIS, RFC2307, RFC2307bis, DBIS, whatever...


This is a purely organizational posting.

*** Please do not follow-up on technical details in this thread!!! ***

Reviewing the recent RFC2307bis/DBIS e-mail thread I think long texts discussing
various topics at once is a real obstacle to get people involved.

I also strongly feel that trying to solve all problems at once with one big
solution will make it really hard to reach some sort of consensus on particular
work items.  Rather people should be able to pick certain aspects to solve part
of the problem in their particular deployment.

I'd vote for dividing the NIS/LDAP topic into several sub-topics already raised
and start separate mail threads:

1. Case-sensitive vs. case-insensitive names
further divided into:
- Scope: POSIX vs. rest-of-world
- User/login names
- Group names
- Service names

2. posixAccount vs. posixUserAccount (DBIS) vs. whatever
- current common posixAccount usage (structural object class etc.)
- gecos field: displayName vs. configurable mapping etc.
- IANA considerations

3. Groups
(Continue reading)

Bannister, Mark | 26 Nov 12:01 2015

Re: DBIS commentary

Hi Jordan,

This is all excellent feedback, thanks, I really appreciate the time you have taken to provide your
comments.  Many of the points you raise I did spend a long time considering myself when I was
writing the internet drafts, so I hope to provide you with more insight into my rationale and why
I decided to do things the way I did.

I hope you don't mind but I'm copying it to the ldapext mailing list, so that others can also
comment if they wish.  For others, Jordan is commenting from the DBIS/RFC2307
schema comparison and not directly from the internet drafts:

Jordan Brown wrote:
> High-level comments:
> - In general, our direction is towards X.500 compatibility and Active Directory compatibility.  I would
>   resist new mechanisms that duplicate those.
> - As noted in more detail below, I consider case-insensitive processing to be the correct direction and
>   would resist moves towards case sensitivity.
> - Some of the mechanisms here (e.g. gecos mapping) seem to duplicate RFC 4876 profiles.

Thanks for the summary, I'll answer these points individually as I get to them below.

> Footnote 1 says that published classes may not be redefined. Although not all changes seem permissible,
> some changes (e.g. addition of MAY elements) seem like they could be allowed.  Is there a reference for
> this restriction?  Note that between X.521-1993 and X.521-2012 the TelecommunicationAttributeSet had
> an attribute deleted.

I haven't looked for a reference to this restriction, I had learned it from seeing previous exchanges
(Continue reading)

Barry Leiba | 24 Nov 16:07 2015

Re: New LDAPEXT charter

>> > If you want to DBIS within IETG WG this you have to find people willing
>> > to
>> >
>> > 1. work on you on the documents as co-authors or at least reviewers
>> >
>> > 2. develop an independent DBIS implementation
>> Exactly.  (1) is, of course, necessary for any work to proceed in any
>> working group.  While (2) is not strictly necessary according to RFCs
> 2026 and 6410, it's reasonable for a working group (and/or an Area
>> Director) to push for that
> (1) should be possible.  Is there an official process a reviewer needs to
> follow, in order to count as a reviewer for this purpose?

No, people just need to participate in the working group discussions,
and part of that would be the discussions of the documents we're
talking about.

> (2) seems to contradict your first point about a Proposed Standard not even
> needing an implementation.  Please help me understand this.  It is either
> required or not required in my case?

There's no contradiction: there's no IETF rule that requires
implementations for PS.  That said we don't want to spend a lot of
time developing proposed standards that no one will deploy.  So it's
reasonable for a working group to decide, by its own consensus, that
it doesn't want to work on something unless the working group is
satisfied that there's a commitment to implement and deploy it.

(Continue reading)

Michael Ströder | 24 Nov 15:49 2015

OATH-LDAP as ldapext WG item?


Anyone here interested in co-authoring an I-D describing OATH-LDAP (presented
at LDAPcon 2015)?

Is there general interest to add this as ldapext WG item?

I have a schema for HOTP/TOTP (see attachment) and a reference implementation
for HOTP and some thoughts on operational considerations. TOTP schema might
need some small work and I have to adapt the implementation.

Ciao, Michael.
# Schema for OATH-LDAP
# $Revision: 1.4 $
# Author: Michael Ströder <michael <at>>
# This schema is meant to be used along with normal password authentication
# therefore it does not replace 'userPassword' attribute values.
#      +--------+
#      | person |<-----------+
#      +--------+            |
#          ^            +----+-----+
#          |            | account  |
#          |            +--+----+--+
#    +-----+-----+         |    |
(Continue reading)

Ludovic Poitou | 24 Nov 08:46 2015

Next LDAPExt draft charter...

Hi Barry,

Please find below, the initial draft charter for a new working group at IETF on the trail of the LDAPEXT working group (I don’t know if we can reuse the name of a closed WG).

As it’s been discussed on the ldapext mailing list already, the DBIS work has been left out of the draft charter, but possibly could be integrated within the first work element.

Please let us know if this draft charter is acceptable or needs to be adapted to lead to the creation of the Working Group as soon as possible.

Kind regards,


   Working Group Name:
        LDAP Extension (ldapext)

   IETF Area:
        Applications and Real-Time (ART) Area 

        Howard Chu (hyc <at>
        Ludovic Poitou (ludovic.poitou <at>

   Applications and Real-Time (ART) Area Director(s):
        Ben Campbell (ben <at>
        Alissa Cooper (alissa <at>
        Barry Leiba (barryleiba <at>

   Responsible Area Director:
        Barry Leiba (barryleiba <at>

   Mailing Lists:
        General Discussion:ldapext <at>
        To Subscribe:

   Description of Working Group:

   The LDAPExt working group is charter to standardize extensions to
   LDAPv3 (RFC 4510) standards. 
   Some years ago, under the umbrella of a former ldapext WG or as
   individual submissions, several extensions were proposed in the form of
   experimental RFCs and Internet Drafts. Although not finalized, these
   specifications have been implemented by different vendors, with various
   interpretations leading to subtle interoperability issues.
   The working group will do the following:
   Finish existing and implemented Internet Drafts and publish them as
   Proposed Standards:
   * An Approach for Using LDAP as a Network Information Service (RFC
     2307) was published as an Experimental RFC. Soon after, revisions
     appeared as draft-howard-rfc2307bis. The objective is to conclude
     this work in compliance with the IANA guide-lines, but preserving
     interoperability with existing implementations.
   * Define an information model and protocol to support Password Policy
     for LDAP Directories, based on previous work described in
     draft-behera-ldap-password-policy, considering the issues raised in
     draft-zeilenga-ldap-passwords but preserving interoperability with
     existing implementations.

  Define new extensions:
  * An inetOrgPerson 2.0 schema to aggregate the needs and changes for
    entries representing Persons in a Directory.
  * Resolve issues with the representation of Groups in LDAP.

  * Define utility schema descriptions widely used:
    draft-stroeder-namedobject and draft-stroeder-mailboxrelatedobject
  * Define an informational document that describes the various
    representations of hashed password values in the 'userPassword'
    attribute. draft-stroeder-hashed-userpassword-values

   Goals and Milestones:

   Jan 2016    Issue new versions of Groups in LDAP, Utility Schemas and
               Hashed Password Values.
   Apr 2016    Issue first revision Internet-Draft of inetOrgPerson 2.0.
               Issue first revision Internet-Draft on RFC 2307 revision.
               Issue first revision Internet-Draft on password policy.
   Jul 2016    Submit Groups in LDAP, Utility Schemas and
               Hashed Password Values to IESG for publication as an RFC.
   Oct 2016    Submit inetOrgPerson 2.0 schema to IESG for publication as
               an RFC.
               Achieve consensus on RFC 2307 Revision and Password Policy
               for LDAP.
   Jan 2017    Submit RFC 2307 Revision and Password Policy to IESG for
               consideration as a Proposed Standard.

Ludovic Poitou
Ldapext mailing list
Ldapext <at>