Sean Leonard | 26 Oct 23:59 2014

Fwd: New Version Notification for draft-seantek-ldap-pkcs9-01.txt

Hello ldapext:

draft-seantek-ldap-pkcs9 has been updated per the e-mail thread on the topic of “dateOfBirth”, among other things.

Some may disagree with the resolution presented in the new Section 4.1. I am happy write in whatever is the IETF Consensus on the matter.

Sean

Begin forwarded message:

Subject: New Version Notification for draft-seantek-ldap-pkcs9-01.txt
Date: October 26, 2014 at 3:56:06 PM PDT
To: Sean Leonard <dev+ietf <at> seantek.com>, "Sean Leonard" <dev+ietf <at> seantek.com>


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

Name: draft-seantek-ldap-pkcs9
Revision: 01
Title: Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9
Document date: 2014-10-26
Group: Individual Submission
Pages: 7
URL:            http://www.ietf.org/internet-drafts/draft-seantek-ldap-pkcs9-01.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/
Htmlized:       http://tools.ietf.org/html/draft-seantek-ldap-pkcs9-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-seantek-ldap-pkcs9-01

Abstract:
  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.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


Attachment (smime.p7s): application/pkcs7-signature, 6521 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Michael Ströder | 26 Sep 14:23 2014

Revive ldapext WG?

HI!

AFAICS independent draft submissions can only reach informational or
experimental status.

But I think it should be possible to reach standard status for some important
drafts (like ppolicy draft as discussed at LDAPcon 2013).

What do you think about it?
Should IETF WG ldapext should be revived?

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 5750 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Michael Ströder | 26 Sep 14:15 2014

Fwd: New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt

HI!

I've sent this draft to the RFC editor for review.
Anyone here willing to act as reviewer?

Still sorting out some idnits issues for next version but those are only minor
details.

Ciao, Michael.

-------- Forwarded Message --------
Subject: New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt
Date: Fri, 26 Sep 2014 04:59:34 -0700
From: internet-drafts <at> ietf.org
To: Michael Stroeder <michael <at> stroeder.com>, Michael Stroeder
<michael <at> stroeder.com>

A new version of I-D, draft-stroeder-mailboxrelatedobject-06.txt
has been successfully submitted by Michael Stroeder and posted to the
IETF repository.

Name:		draft-stroeder-mailboxrelatedobject
Revision:	06
Title:		Lightweight Directory Access Protocol (LDAP): Auxiliary Object Class
'mailboxRelatedObject'
Document date:	2014-09-26
Group:		Individual Submission
Pages:		5
URL:
http://www.ietf.org/internet-drafts/draft-stroeder-mailboxrelatedobject-06.txt
Status:
https://datatracker.ietf.org/doc/draft-stroeder-mailboxrelatedobject/
Htmlized:       http://tools.ietf.org/html/draft-stroeder-mailboxrelatedobject-06
Diff:
http://www.ietf.org/rfcdiff?url2=draft-stroeder-mailboxrelatedobject-06

Abstract:
   This document defines the auxiliary object class
   'mailboxRelatedObject' that can be used to associate an arbitrary
   object with an Internet mail address.  Furthermore an attribute
   'intlMailAdr' is defined for storing fully internationalized Internet
   mail addresses.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

Attachment (smime.p7s): application/pkcs7-signature, 5750 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Michael Ströder | 22 Sep 09:24 2014

Server implementations of Don't Use Copy control?

HI!

Which LDAP server implement Don't Use Copy control as defined in RFC 6171?
For which use-cases?

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 3244 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Michael Ströder | 22 Sep 09:26 2014

Server implementations of LDAP transactions?

HI!

Which LDAP servers have support LDAP transactions as defined in RFC 5805?
Is it used with any particular use-cases?

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 3244 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Sean Leonard | 11 Sep 21:49 2014

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

Hello ldapext list:

I posted this proposal to add definitions to the IANA registry. These 
definitions are from PKCS #9, which predates ldapext. However, the 
definitions in PKCS #9 never got added. This document adds them.

Feedback is requested, as well as suggestions on how best to proceed 
with this to get IETF consensus.

Thanks,

Sean

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

Name:		draft-seantek-ldap-pkcs9
Revision:	00
Title:		Lightweight Directory Access Protocol (LDAP) Registrations for 
PKCS #9
Document date:	2014-09-10
Group:		Individual Submission
Pages:		6
URL: 
http://www.ietf.org/internet-drafts/draft-seantek-ldap-pkcs9-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/
Htmlized:       http://tools.ietf.org/html/draft-seantek-ldap-pkcs9-00

Abstract:
    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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
Michael Ströder | 10 Jan 20:32 2014

Re: DBIS - new IETF drafts

Simo wrote:
> On Thu, 2014-01-09 at 21:45 +0100, Michael Ströder wrote:
>> Simo wrote:
>>> On Thu, 2014-01-09 at 19:08 +0100, Michael Ströder wrote:
>>>> Simo wrote:
>>>>> The full schema definitions can be found here:
>>>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60basev2.ldif
>>>>
>>>> Looked at the schema:
>>>>
>>>> I'm a bit confused by some object classes directly referencing MAY memberOf.
>>>> 'memberOf' is normally an operational attribute also in 389 DS isn't it?
>>>
>>> It is a generated by the memberof plugin, it's semantics are different
>>> from other solutions (like AD), all descendants are resolved at modify
>>> time.
>>
>> Really different semantics?
>>
>> AFAIK memberOf should be a simple back-link from the member's entry to the
>> group entry. When the attribute value is actually created (on modify or on
>> read) is not relevant for memberOf semantics. Or did I get you wrong?
> 
> It is not a backlink in FreeIPA.
> 
> If you have:
> groupA:
>    member: GroupB
> 
> groupB:
>    member: userC
> 
> then userC's memberof is:
> 
> userC:
>   memberOf: groupA
>   memberOf: groupB
> 
> This makes initgroups a lot more efficient as it is a single dereference
> search to get all groups a user directly or indirectly belongs to.

(Sigh!) You took the attribute type NAME and OID from MS AD:

( 1.2.840.113556.1.2.102
  NAME 'memberOf'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
  NO-USER-MODIFICATION )

But you've changed the semantics. In AD 'memberOf' does not(!) include nested
group membership.

That's really bad practice and makes client developers live really miserable!

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 3244 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Mark R Bannister | 10 Jan 15:13 2014
Picon

Re: DBIS - new IETF drafts

On 09/01/2014 18:03, Simo wrote:
> On Thu, 2014-01-09 at 16:48 +0100, Michael Ströder wrote:
>> Mark R Bannister wrote:
>>> Yes as you'll see from my recent reply to Simo, the case sensitivity issue was
>>> one of the problems I faced at a large installation,
>> This could be easily solved with RFC2307bis. Or not?
>>
>> In my deployments I simply define additional (OpenLDAP) constraints for those
>> attributes (e.g. to enforce lower-case 'uid' values).
>>
>> IMHO only re-defining the matching rules does not fully solve the case problem
>> anyway. Restricting to lower-case attribute values helps better.
>
> I'd go beyond this, supporting case-sensitive user names is actively
> harmful for various reasons.

UNIX is traditionally case sensitive.  I am currently working at a large 
installation where there is an important distinction between lower-case 
and upper-case user names.  This debate isn't just about user names 
anyway.  There are loads of NIS fields that were case sensitive, and 
UNIX isn't going to change.  They will always be case sensitive.  So 
trying to represent them in case insensitive fields is just, well, wrong.

> - Assuming users (and admins) should be able to distinguish based on
> case is wrong, we naturally consider the strings 'Admin' and 'admin' to
> be the same thing.

If you're used to Microsoft Windows, yes.  DBIS is not aimed at Microsoft.

> - Some systems are case-preserving (meaning they'll show you back the
> same case you entered, but are really case-insensitive and if you have
> to interoperate with them you cannot assume Admin and amdin to be
> different users, it could lead to serious security issues.
>
> - If we are in the legacy game, there are still systems that will simply
> accept only all caps names, like ADMIN. In these cases what do you map
> that to ? Admin ? admin? a third user called ADMIN ?
>
> And there are many other examples where really being case sensitive
> causes a lot more problem than it resolves.
> Due to these problems what we did in FreeIPA is to always create users
> in lower case and explicitly state we are case-preserving and
> insensitive. It is the only reasonable compromise IMHO.

NIS, RFC2307, RFC2307bis and DBIS are for UNIX.  UNIX is case 
sensitive.  It makes no sense to store data in a case insensitive 
fashion if the client expects it to be case sensitive.  Data loss or 
corruption will occur this way.

Best regards,
Mark.

_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Michael Ströder | 10 Jan 11:40 2014

Re: DBIS - new IETF drafts

Simo wrote:
> On Thu, 2014-01-09 at 21:36 +0100, Michael Ströder wrote:
>> Simo wrote:
>>> On Thu, 2014-01-09 at 16:48 +0100, Michael Ströder wrote:
>>>> Resolving nested group membership is a big performance cost. I can see this
>>>> with a MS Sharepoint installation working with a OpenLDAP server. Sharepoint
>>>> sends many search requests even though nested groups are not used in this
>>>> deployment.
>>>
>>> Performance issues with nested groups can easily be solved via caching
>>> and the deref control though.
>>
>> But the deref control gives you only one level. Speaking of nested groups in
>> general people mean more than just two-level group memberships.
> 
> It's an 80/20 thing, the most common case is 2 levels deep, so the worst
> case is not usually a big issue.

But if you don't enforce the 2-level-nested-groups limit the client has to
search for nested groups and deref control does not help.

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 3244 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Michael Ströder | 9 Jan 21:45 2014

Re: DBIS - new IETF drafts

Simo wrote:
> On Thu, 2014-01-09 at 19:08 +0100, Michael Ströder wrote:
>> Simo wrote:
>>> The full schema definitions can be found here:
>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60basev2.ldif
>>
>> Looked at the schema:
>>
>> I'm a bit confused by some object classes directly referencing MAY memberOf.
>> 'memberOf' is normally an operational attribute also in 389 DS isn't it?
> 
> It is a generated by the memberof plugin, it's semantics are different
> from other solutions (like AD), all descendants are resolved at modify
> time.

Really different semantics?

AFAIK memberOf should be a simple back-link from the member's entry to the
group entry. When the attribute value is actually created (on modify or on
read) is not relevant for memberOf semantics. Or did I get you wrong?

>> Also I don't understand the rationale for object class nestedGroup SUP
>> groupOfNames with memberOf.
> 
> Not sure where's the confusion.

I'm confused by seeing an operational attribute like 'memberOf' being defined
in user schema.

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 3244 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Michael Ströder | 9 Jan 21:36 2014

Re: DBIS - new IETF drafts

Simo wrote:
> On Thu, 2014-01-09 at 16:48 +0100, Michael Ströder wrote:
>> Mark R Bannister wrote:
>>> Yes as you'll see from my recent reply to Simo, the case sensitivity issue was
>>> one of the problems I faced at a large installation,
>>
>> This could be easily solved with RFC2307bis. Or not?
>>
>> In my deployments I simply define additional (OpenLDAP) constraints for those
>> attributes (e.g. to enforce lower-case 'uid' values).
>>
>> IMHO only re-defining the matching rules does not fully solve the case problem
>> anyway. Restricting to lower-case attribute values helps better.
> 
> 
> I'd go beyond this, supporting case-sensitive user names is actively
> harmful for various reasons.
> 
> - Assuming users (and admins) should be able to distinguish based on
> case is wrong, we naturally consider the strings 'Admin' and 'admin' to
> be the same thing.
> 
> - Some systems are case-preserving (meaning they'll show you back the
> same case you entered, but are really case-insensitive and if you have
> to interoperate with them you cannot assume Admin and amdin to be
> different users, it could lead to serious security issues.
> 
> - If we are in the legacy game, there are still systems that will simply
> accept only all caps names, like ADMIN. In these cases what do you map
> that to ? Admin ? admin? a third user called ADMIN ?
> 
> And there are many other examples where really being case sensitive
> causes a lot more problem than it resolves.
> Due to these problems what we did in FreeIPA is to always create users
> in lower case and explicitly state we are case-preserving and
> insensitive. It is the only reasonable compromise IMHO.

So basically you're doing the same thing like I described above.

>>> Nested groups are very important especially in large enterprises, and really
>>> do assist with data management.
>>
>> I am always getting told this but I have strong doubts about nested groups.
> 
> Great value at least in IPA, we use them a lot to associate things like
> permissions to roles to groups and ultimately to users (All through
> nesting each of these as groupsofnames). It does really make some
> problems much easier to handle at the end of the process.

Which problems are easier? Personally I'd definitely consider abusing
groupOfNames for permissions bad schema design.

>>>  Yes we'll get more search operations, but I
>>> don't think this will be a problem.  I should be able to prove this will work
>>> in my reference implementation.
>>
>> Resolving nested group membership is a big performance cost. I can see this
>> with a MS Sharepoint installation working with a OpenLDAP server. Sharepoint
>> sends many search requests even though nested groups are not used in this
>> deployment.
> 
> Performance issues with nested groups can easily be solved via caching
> and the deref control though.

But the deref control gives you only one level. Speaking of nested groups in
general people mean more than just two-level group memberships.

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 3244 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext

Gmane