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

Re: UTF8 case insensitive matching

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

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.

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

Even worse: In my application I have to deal with ASN.1 structure of
certificate DNs and mapping it to LDAP DNs...

Ciao, Michael.