[Date Prev][Date Next]
Re: UTF8 case insensitive matching
At 05:00 PM 11/1/00 +0100, Michael Ströder wrote:
>"Kurt D. Zeilenga" wrote:
>> 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,
>What does "unnecessary escaping" mean?
A client is free to escape any character in the attribute value.
For example, a client could escape everything but printable ASCII.
As part of the "pretty" process, only those characters which
require escaping per RFC 2253, 2.4, would be escaped in DNs
returned by servers.
>This whole thing is weird: If you e.g. parse a RFC2253 DN string
>with hex-escaped UTF-8 chars it's pretty hard to figure out if the
>hex-escaped chars should be kept as is or transferred to UTF-8.
Actually, it's not hard at all. The escaping is just an encoding
mechanism. The "pretty" routine just decodes per the grammar
then recodes to provide a DN in the more restrictive form.
>> 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.
>AFAIK RFC1779 allows ; as DN component delimiter instead of ,. How
>do you determine whether ; or , is used as delimiter? Or you add it
>to your "avoid-list".
If the ';' is not escaped per RFC1779 then it's part of the value.
Note that though RFC2253 disallows use of ';' as a separator in
LDAPv3 DNs, it does require that ';' in values be escaped.
>Even worse: In my application I have to deal with ASN.1 structure of
>certificate DNs and mapping it to LDAP DNs...
If the client as a BER encoded DN, the client should map to an
LDAP DN as described in RFC 2253, Section 2. If the client has
the DN in some other form (such as the traditional X.500 string
representation), it should convert to BER and go from there.