https://bugs.openldap.org/show_bug.cgi?id=9495
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|SUSPENDED |INVALID
--- Comment #5 from Howard Chu hyc@openldap.org --- (In reply to Karl O. Pinc from comment #3)
On Mon, 14 Jun 2021 16:39:43 +0000 openldap-its@openldap.org wrote:
https://bugs.openldap.org/show_bug.cgi?id=9495
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added
Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- Invalid usage.
SASL works with usernames, not DNs. I.e., -U "cn=..." is invalid.
RFC4422 Simple Authentication and Security Layer (SASL) states:
3.4.1. Authorization Identity String
The authorization identity string is a sequence of zero or more Unicode [Unicode] characters, excluding the NUL (U+0000) character, representing the identity to act as.
So, the literal "cn=..." is a perfectly valid SASL username.
You should read the entire text of that section.
A non-empty authorization identity string indicates that the client wishes to act as the identity represented by the string. In this case, the form of identity represented by the string, as well as the precise syntax and semantics of the string, is protocol specific.
While the character encoding schema used to transfer the authorization identity string in the authentication exchange is mechanism specific, mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character).
A literal of the form "cn=..." is only valid if the protocol defines it to be valid. The particular SASL mechanism must support it for it to be valid.