[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt

Andrew Sciberras wrote: 
Hi Howard,

I am curious as to what the intended publication status of this draft will be (i.e. experimental, informational, etc)?

Hi Andrew, thanks for the feedback. This draft is intended to be published as Informational only. It was supposed to reflect what we've been using in OpenLDAP for the past several months to provide ordering for attributes in our server config DIT, but things have already diverged in the intervening time. On the off chance that other implementors would want to adopt this approach, it would make sense to fix this up.

I would have concerns about the proposed strategy if this was a Standards Track document.
The main concerns that I have about the draft in its current form are that:

1. *Values that do not conform to the syntax*
I agree with your statement in 2.2 that:
"Using this extension on an attribute requires that ordering-prefix is a legal value of the LDAP syntax of that attribute."

This statement is broken for Ordering Siblings and EXAMPLE_AT.2. A Distinguished Name is not allowed to start with a curly brace '{'.

2. Which attributes can use this extension?
The following statement is present in section 3.1:
" In general this extension is only compatible with AttributeTypes that have a string-oriented syntax."

I think that we need to be more specific about the syntaxes that can use this functionality. I would be inclined to restrict it to Directory String, IA5 String and Octet String .

Yes, these are both good points; I think I was hedging a bit too much when I wrote those statements. The actual implementation in OpenLDAP strips the prefix before dropping into the underlying syntax's validators/normalizers, so it actually works for any syntax. The extension wouldn't be as useful if it was limited to only a few syntaxes; I'll have to come up with some new language here.

3. Interoperability Problems
This functionality will cause severe problems between client and server interoperability. A likely case that can exist, is when we have a server that implements x-ordering, and a client that doesn't.
When the client gets results back, it will most likely reject (or fail to decode) any DN value that contains ordering information. Any values that are returned with ordering information will be treated as-is. This will cause the ordering information to be treated as part of the attribute value, which may cause problems with the client.
I cannot see any way of informing an unaware client that the ordering data in the value have special semantics.

A bigger problem is that a client cannot indicate that they don't want additional ordering information prepended to values. An x-ordering aware client, who doesn't care about ordering, will need to read schema and identify which attributes have been subjected to ordering data, and then remove it. 

Perhaps we should investigate use of a control, as you suggested in (6).

Part of the rationale for making the prefix always present was so that it would be transported along with the data when passing through unaware agents. The idea being that even a server that didn't support the extension could store the data, and even if it returned values in arbitrary order, an aware client could sort it back into the intended order. But obviously that only works when the prefix is legal for the syntax, which brings us back to your (1) and (2).

4. Modification of AttributeTypeDescription is inappropriate and incomplete.
Section 3.1 states:
" The "X-ORDERED" schema extension is added to an AttributeTypeDescription to signify the use of this ordering mechanism."

Whilst this is acceptable in LDAP, the X- extension is intended for private extensions and should not be standardized. The consequence of updating the Attribute Type Description in a doc like this is that any LDAP server that supports this extension will not be able to encode the value in any encoding other than the LDAP specific string encoding (i.e. you wont be able to BER or GSER encode an attributeTypeDescription value).

That probably should have been "AttributeType definition"; we definitely are not passing the extension string around on attributeType descriptions in protocol transactions.

5. Security Considerations
Security consideration should include additional information. The x-ordering semantics could be used for retaining a password history by simply adding values to the {0} position and only looking at the first x values. The problem here is that this draft is changing the semantics of matching rules (and the semantics of the absence of matching rules) by permitting assertions to be made only on ordering information. This could lead to the disclosure of information, without the client being required to know anything about the values it holds.

I'll add a note to that effect. This capability is already called out at the end of section 4.2. I saw it as an asset not a liability, but I see your point.

6. Matching Semantics
The document doesn't indicate how ordering-prefixes should be matched. My common sense tells me that {0} is equal to {00} and {01} is equal to {1}, but the I-D should explicitly state whether we're comparing integers or strings. 

Yes, integers. I'll add an explicit statement for this.

I think that a better implementation of this functionality would ensure that the functionality is only exercised if the client supports the functionality and it requests its usage. I think its pointless advertising a feature which indicates an uncontrollable change in the semantics of the protocol, as clients should refuse to work with any LDAP server that contains unknown features since they cannot establish how the protocol has changed.

Possibly the solution should incorporate the usage of controls or ldap attribute options.

Cheers,

Thanks again, you've reminded me there's a lot more to think about still.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext