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

From: Andrew Sciberras <[email-masked]>
Date: Wed, 10 May 2006 16:12:59 +1000

Hi Howard,

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

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 .

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.

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

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.

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.

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,

-- 

Andrew Sciberras, CISSP
Solution Architect
eB2Bcom Pty Ltd

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Howard Chu <[email-masked]>
Date: Wed, 10 May 2006 01:20:27 -0700

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

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

> identify which attributes have been subjected to ordering data, and then 

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

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

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

> {1}, but the I-D should explicitly state whether we're comparing 

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

> Possibly the solution should incorporate the usage of controls or ldap 
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/

---

From: Howard Chu <[email-masked]>
Date: Fri, 12 May 2006 06:59:08 -0700

Another pass.

> will be (i.e. experimental, informational, etc)?

Informational.

> Distinguished Name is not allowed to start with a curly brace '{'.

Actually Ordered Siblings is fine since the prefix precedes the RDN 
value, not the RDN type.

> identify which attributes have been subjected to ordering data, and then 

As I see it there are three possible outcomes:
   1) the client is totally unaware of schema - in this case the client 
treats everything as blobs, and doesn't care.
   2) the client is schema-aware, but doesn't recognize the x-ordering 
schema extension - in this case, the client should probably treat the 
attribute as unrecognized. It seems that the ldapbis-models doc doesn't 
really address what to do about unrecognized extensions.
   3) the client is schema-aware and recognizes the schema extension - 
then it should just deal with it. I.e., it is as much a property of the 
attribute as "numericString may only contain digits 0-9".

> you wont be able to BER or GSER encode an attributeTypeDescription value).

I obviously misunderstood you the last time around. The original goal 
here was not standards track, thus the X- extension. If there's 
sufficient interest in a generally usable ordering feature, then we can 
explore that path.

Looking at the current BCP64 draft, there's no procedure for registering 
new schema definition elements.
> Possibly the solution should incorporate the usage of controls or ldap 

The use of attribute options was another possibility that we'd 
considered in the past. It's awkward, since items with different tagging 
options are actually separate attributes. E.g.
	attr-foo;x-order0: first value
	attr-foo;x-order1: second value

It also does not give a client the choice to use the feature or not. 
Also it precludes the Ordered Siblings capability, since attributes in 
RDNs cannot have any options.

---

From: <[email-masked]>
Date: Thu, 18 May 2006 12:00:42 +1000

Hi Howard,

Thanks for your feedback.

See my responses below:

> -----Original Message-----
> From: Howard Chu [mailto:[email-masked]] 
> Sent: Friday, 12 May 2006 11:59 PM
> To: [email-masked]
> Cc: Ldapext
> Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt
> 
> Another pass.
> 
> Andrew Sciberras wrote:

 <snip>

> Actually Ordered Siblings is fine since the prefix precedes the RDN 

That's right.. A silly oversight by me. Ordered Siblings is fine, whilst the
distinguishedName attribute olcSuffix still break the DN syntax.

> treats everything as blobs, and doesn't care.

Ok, this sounds reasonable to me.

> really address what to do about unrecognized extensions.

I would imagine that the handling of private extensions to well defined
schema elements and attribute type definitions should be implemented in a
way that they can be ignored if unrecognised. This relies on the private
extension not changing the semantics of the protocol though. 

Model's isn't explicit about how clients and severs should handle
unrecognised extensions, but it does state:
- extensions to schema elements must start with "X-"
- Anything starting with "X-" are reserved for private experiments

This leads me to think that any schema extensions are for private use only
and cannot be standardised, which is possibly why BCP doesn't allow for
extensions to be registered. It's obviously fine in this case, since the
draft is Informational and can be perceived as providing information about a
private extension used in an existing implementation. I think the problem is
that clients that do not support the extension, should not be delivered
information that has been modified for the purpose of the extension. 

Andrew Sciberras
eB2Bcom