LDAPprep

[David Wilson <David.Wilson@isode.com>]

I've been looking at draft-ietf-ldapbis-strprep-07, and there seems to
be a serious problem in the area of substring matches.

Section 2.6.1 states that if the string contains any non-space
characters then it is modified to start and finish with a space, and any
internal sequences of spaces are altered to be two spaces. This appears
to apply to substring filter strings. (The following paragraph has a
specific exception for these for the case of only spaces in the value).

But if this is done, and you have, say,

        (cn=*bar*)

that is not going to match a value of "foobar", as the 'any' string
becomes "<SPACE>bar<SPACE>" by the above rule, the value being matched
becomes "<SPACE>foobar<SPACE>" which does not contain the substring.

The overall scheme would work, but you need more complicated rules for
substring filter strings. Inner sequences of spaces become two spaces.
Leading or trailing sequences become one space, but spaces are NOT added
at the ends except:

- a space at the start of an initial substring
- a space at the end of a final substring

I have two other minor comments on this draft, not directly related to
the above.

draft-ietf-ldapbis-syntaxes-11 does not change the definition of the
telephone number syntax nor the definition of facsimile telephone
number. In both cases the number is a PrintableString. So, I'm not sure
why "2.6.3 telephoneNumber Insignificant Character Handling" needs to
make allowance for non-PrintableString hyphen-type characters.


In Appendix B, an alternative scheme for insignificant space handing is
described. In conjunction with substring matching, this alternative
scheme tends to make substrings in the filter shorter, by removing
leading and trailing spaces. Therefore you get matches which you don't
expect, rather than not getting matches you do expect. In particular,
the first case erroneously states that (with this mechanism) (cn=foo\20*
\20bar) would NOT match CN values "foo<SPACE>bar" and
"foo<SPACE><SPACE>bar", but it would. The initial and final substrings
are reduced to "foo" and "bar", and so match the prepared values, which
both become "foo<SPACE>bar". The same applies to the third example,
which uses the same filter and one of the same value strings.

cheers

David Wilson
Isode Limited