Reject unescaped special characters in DN values per RFC 4514

[t2y]

Background

I ran into a case where ldap.ParseDN accepted a DN like the following without returning an error:

uid=john<doe,ou=engineering,dc=example,dc=com

This prompted me to re-read the DN string specification, and I noticed that several of the special characters listed in RFC 4514 were not being checked for the unescaped form.

Summary

ParseDN previously accepted ", ;, <, >, and NULL (U+0000) in their raw, unescaped form, silently producing AttributeTypeAndValue values that violate the RFC 4514 grammar. Such values can be misinterpreted by downstream
LDAP servers or by string-comparison code that assumes a well-formed DN, which is both a correctness issue and a potential security concern (e.g. DN-based authorization checks operating on a value the server later parses differently).

Changes

• decodeString now returns an error when it encounters any of ", ;, <, >, or NULL in unescaped form. The hex-escape (\XX) and backslash-escape (\X) forms continue to decode unchanged, so previously valid inputs are unaffected.
• TestSuccessfulDNParsing is expanded to cover every RFC 4514 §2.4 escape target in both escape forms (e.g. \, and \2C). NULL is covered only in the hex form, as required by the RFC.
• TestErrorDNParsing and TestDecodeString gain matching negative cases for each unescaped character, so the new rejection path has full coverage.

Notes / Caveats

• Leading/trailing U+0020 (SPACE) is intentionally left lenient. RFC 4514 requires SPACE at the start/end of a value to be escaped, but the existing whitespace-stripping behavior is relied upon by many real-world inputs. Tightening this is deferred to a separate change to keep this PR backward-compatible for common usage.

Compatibility

This is a behavior change: callers that were (incorrectly) passing raw ", ;, <, >, or NULL into ParseDN will now receive an error instead of a silently malformed DN. Callers using properly escaped input are unaffected.

Disclosure on AI assistance

In the interest of transparency:

• The core fix in v3/dn.go (rejecting unescaped special characters in decodeString) was designed and written by me.
• The additional test cases in v3/dn_test.go and the wording of this PR description were drafted with the help of an AI agent. I reviewed every test case against RFC 4514 §2.4 and confirmed the expected behavior locally before submitting.

Happy to adjust or rewrite any part of the AI-assisted content if the maintainers prefer.

References

• RFC 4514, Section 2.4 — Converting an AttributeValue from ASN.1 to a String

[t2y]

If, for any reason, you would prefer not to change the behavior of ParseDN, would it be better to introduce a separate ValidateDN function instead?

[cpuschma]

If, for any reason, you would prefer not to change the behavior of ParseDN, would it be better to introduce a separate ValidateDN function instead?

Having multiple ParseDN functions could cause confusion. I suggest fixing the current implementation and adding a note to the next release instead. After all, the current behaviour is unintended and does not conform to the RFC.