Re: Error searching DNs with escaped special characters

[Nikita Bige <big_nikita@mtu-net.ru>]

On Monday 21 July 2003 23:07, Pierangelo Masarati wrote:
> Actually, rethinking my previous post, the latter is correct:
>
>     dn: x509issuer=CN=test \5C\22sa\5C\22 sadf\,C=RU,O=ca
>
> while this is wrong:
>
>     dn: x509issuer=CN=test \22sa\22 sadf\,C=RU,O=ca
>
> Another perfectly legal form is:
>
>     dn: x509issuer=CN=test \\\"sa\\\" sadf\,C=RU,O=ca
>
> Let me elaborate on this (I couldn't wonder what yoo were
> going to escape until Michael Stroeder directed me to the
> schema definition of x509issuer :)
>
> Your DN holds, as RDN, an attribute whose syntax is
> distinguishedName.  Then, the attribute value, in string
> representation, is:
>
>     CN=test \"sa\" sadf,C=RU
>
> note that the double quotes are escaped because inside
> a DN, while the comma isn't because it is separating
> a RDN from its parent.
Thank you for complete explanation

But I am thinking that this behavior of slapd not right
and does not correspond RFC2253.

> When whis value is used inside another DN, all the special
> chars it contains must be escaped further;
??? Why it MUST be escaped further???
Where are this behavior described in RFC???

> so its escape
> value becomes:
>
>     CN=test \\\"sa\\\" sadf\,C=RU
>
> note that backslash itself needs be escaped; the same
> applies to the quotes, as seen before.  The comma must
> also be escaped because now it is part of a single value
> in a RDN.  As a results you get
>
>     x509issuer=CN=test \\\"sa\\\" sadf\,C=RU,O=ca
>
>                \-----DN-valued attr--------/
>     \-----------------RDN------------------/
>
> This is what slapd currently interprets as I expect.
>
> p.

-- 
Wbr
Nikita