Re: Stringprep Considered Harmful

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

(combining responses)
At 12:27 AM 11/12/2004, Steven Legg wrote:
>Rici,
>Rici Lake wrote:
>>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 doubt the working group as a whole has the background to give
>due consideration to the issues around bidi. I know I don't.
>I think prior consensus here probably amounts to a lot of
>"I dunno, whatever".

Well, I don't give much weight to "I dunno, whatever"
opinions in consensus determination.

In respect to LDAPprep, there seems to enough folks (not
just LDAPbis regulars) engaged in LDAPprep discussions who
understand Stringprep/Unicode issues well enough to form an
opinion as to which of the two BIDI options Stringprep should
be used.  I note that throughout the engineering of LDAPprep,
the WG has repeatedly and regularly consulted with area
experts.  The BIDI restrictions were, in fact, added after
discussions with various Stringprep/Unicode experts (as I
noted in a post last year).

>>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.
>
>The situations you have described seem to me to be quite reasonable
>uses of the directory. It is unfortunate if LDAPprep + stringprep
>is making those things illegal.

But one has to consider whether those same things are reasonable
for directory strings in general.  In particular, one has to
carefully consider the Security Considerations outlined in 9.1
of [Stringprep] apply to directory strings.  It would seem
these considerations apply well to values commonly used for naming
and in security applications (such as PKIX), and even descriptive
text.

>>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]+)

Regardless of the BIDI issue, caseIgnore*Match/caseExact*Match
are inappropriate rules for matching URLs as the rules are not
aware of the particulars of the URL syntax, such as escaping.

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

There is no standard way to use Arabic or Hebrew in
mailbox names.  The existing 'mail' attribute is restricted
to IA5

As for domain components, in LDAP, domain components
should be IA5 strings (constrained to the appropriate
LDH subset).  IDNA likely should be applied above the
directory for interoperability reasons.  Or new attributes
are introduced with a Unicode-allowing syntax, they can be
introduced with new matching rules.

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

Regardless of the BIDI issue, case{Ignore,Exact}*Match
are inappropriate rules for matching DN strings as the rules
are not aware of the particulars of the DN string syntax,
such as escaping.

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

Though you didn't detail what kind of file path you were
referring to, but I would suspect that case{Ignore,Exact}*Match
are inappropriate for most if not all common file path syntaxes
(due to significant space issues, escaping, and various other
issues).

>>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.
>
>Seems like a fair assertion to me.

I view all of cases listed as being application-specific cases
where the general purposes matching rules (and possible the
directory string syntax) simply are inappropriate.  These special
cases would be better handled by application-specific matching
rules.

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

The BIDI restrictions are appropriate for most (if not all of)
the standard track attribute types using these matching rules,
especially in light of various security considerations (such
as those elaborated on in 9.1 of [Stringprep]).

Kurt