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

Re: Stringprep Considered Harmful


On 11-Nov-04, at 11:21 AM, Kurt D. Zeilenga wrote:

In revising the LDAP technical specification, the WG was
charged with resolving known interoperability problems,
including those in character string matching.  I believe
the WG understood (and understands) that fixing the general
character string matching problems requires invalidating
(or "breaking") some specific application uses of LDAP.  I
also believe the WG understands well the limitations of the
Stringprep solution and accepts those limitations as
reasonable given the situation.


I find that acceptable for most of the little quirks of the
stringprep profile proposed. But I would beg the WG to
reconsider the application of the bidi-prohibition rule.

To try to make the problem as simple as possible, all of the
following strings would be unmatchable with bidi-prohibition:

1) A URL which contains an Arabic or Hebrew component, whether
a domain component, path component or query component, unless
%-quoted. (This might even be an ldap: url.) These will be
unmatcheable because a URL must start with a scheme name,
all of which currently are left-to-right characters (in fact
[a-z0-9]+)

2) An email address which contains an Arabic or Hebrew
domain name component or Arabic or Hebrew mailbox name,
unless the entire domain name include the TLD is in
Arabic or Hebrew. (I know that there is a proposal to
implement Arabic TLDs, but I feel that <arabicword>.com
is rather more likely in the forseeable future.)

3) A string not identified as having distinguished name
syntax which happens to be a distinguished name which
includes Arabic or Hebrew components

4) An absolute filepath which includes Arabic or Hebrew
components, even if all components are Arabic or Hebrew, since
the initial / will fail the bidi prohibition

5) And a long etc.

So it seems to me that the bidi prohibition is more the exception
than the rule; it should be applied to the syntax for the dc
attribute, but it is hard to think of other attributetypes where
it will not primarily serve block the use of right-to-left scripts.

Your comment "this may indicate the need for more MatchingRules
which correspond to those system's matching algorithms" is on
target.  Where the general-purpose matching rules (e.g.,
caseIgnoreMatch, caseExactMatch, etc.) are inappropriate in
some application-specific context, an application-specific
matching rule should be introduced OR the application should
specify that application-specific transformations (e.g., IDN
toASCII/toUnicode) be employed above the directory such that
matching with general purpose matching rules (e.g.,
octetStringMatch) in the directory behaves in a manner
appropriate for the application.


That seems entirely appropriate to me. Consequently, I would humbly
suggest that the default general-purpose matching rule not include
the bidi prohibition rule, and that an application-specific rule
be introduced for attributes whose values will be normalised by
nameprep.

Rici