dnValidate (was: Re: UTF8 case insensitive matching)

["David A. Cooper" <david.cooper@nist.gov>]

Based on earlier discussions, I have been working on a version of dnValidate that will read in a distinguished name that was generated based on RFC 2253 (or RFC 1779) and will return a normalized version of that string (compliant with RFC 2253).

The code that I produced will handle attribute values of type Directory string whether they are provided as a string, a quoted string, or a BER encoded string. It can similarly handle attribute values of type bitstring.

Unlike the dnValidate function currently in servers/slapd/schema_init.c, I have added two additional parameters: make_uppercase and compress_whitespace.

If make_uppercase is set, then all of the characters in the string are made uppercase (using uctoupper), otherwise the cases of the characters in the attribute values are left unchanged.

If compress_whitespace is set, then all leading and trailing whitespace characters are removed from attribute values and sequences of whitespace characters between "words" in an attribute value are replaced by a single space. If compress_whitespace is not set, then only those leading and trailing whitespace characters that are not considered to be part of the attribute value according to RFC 2253 are removed. For example, if compress_whitespace is set, the string 'cn =  \20 David  Cooper \20  ' would be compressed to 'cn=David Cooper', whereas it would become 'cn=\20 David  Cooper \20' if compress_whitespace were not set.

At the moment, I have not attempted to merge my version of dnValidate into the slapd code, but I have written the code in a way that should make this relatively straightforward. In the meantime, I have written a very short program that reads in a DN from the command line and prints out its normalized form.

If you would like to see what I have done, I have posted the code on our Web site as a compressed tar file (about 10 Kbytes) at:

                 http://csrc.nist.gov/pki/testing/dnValidate_test.tgz

For my own purposes, for the short term, my plan is to re-write dn_validate and dn_normalize as functions that call my version of dnValidate and then overwrite the original string with the string returned by dnValidate (if the normalized string will fit).

If anyone has any ideas on a cleaner long-term solution to integrating this function (as Kurt suggested below) or any other comments on this code, please let me know.

Thanks,
David Cooper

At 11:38 AM 10/31/00 -0800, Kurt D. Zeilenga wrote:
>There are a number of additional DN issues which need to be addressed.
>LDAPv2 and LDAPv3 have different DN encoding requirements.  Though the
>LDAPv3 DN form (RFC 2253) can be viewed as a subset of the LDAPv2
>specification (RFC 1779) form, but there are other requirements
>(e.g.: LDAPv2 restricts an LDAPDN to IA5, LDAPv3 restricts to UTF-8).
>
>When talking LDAPv2, a server must accept and produce RFC 1779 DNs.
>When talking LDAPv3, a server must accept and produce the restricted
>  DN form defined RFC 2253s.
>
>I suggest we allow the more liberal RFC1779 in both LDAPv2 and LDAPv3
>but only store (and produce) DNs in the RFC 2253 restricted form for
>both LDAPv2 and LDAPv3.  I also suggest we ignore the LDAPv2 IA5
>restriction.
>
>This implies that we not only validation and normalization functions,
>but a DN "pretty" function.  To "pretty" the DN, the DN would be parsed
>per RFC 1779 and then rebuilt per RFC 2253, Section 2.  We'd avoid
>unnecessary escaping, use the hexpair escaping form verses the escape
>prefix form, avoid OIDs, avoid BER encoded values, etc.  To normalize,
>we'd parse per RFC 1779, normalize the value per its syntax, then
>rebuild per RFC 2253.
>
> >Ideally, I would like to fix the dn_validate() function so that all three of these strings normalize to the same result. While I don't think that I'll be able to fix things so that any arbitrary DN can be normalized, I would like to get as close as possible.
>
>Note that we don't have to implement all possible DN forms.  A number of the
>forms we may disallow.  It particular, we may be quite selective of what values
>we accept in BER form.
>
> >One problem that I have, though, is that since DNs must currently be normalized in place,
>
>The long term approach is to replace dn_validate/dn_normalize with
>dnValidate/dnNormalize/dnPretty.  This resolves the in place issue.
>
> >Similarly, if I always normalized to a quoted representation,
>
>Note that we must not produce the quoted representation in LDAPv3.  It's only
>allowed in LDAPv2.
>
> >If an alternative solution (i.e., one that allows normalization to increase the length of a DN) will be available, then I will abandon my current approach and wait until a cleaner solution can be implemented.
>
>We need to shift to using dnValidate/dnNormalize/dnPretty....
>This is significant work.