[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] Comments: draft-chu-ldap-xordered-00.txt
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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext