https://bugs.openldap.org/show_bug.cgi?id=9318
--- Comment #3 from dar@xoe.solutions --- Interesting, although in appendix B, the most specific paragraph discourages explicitly it's use, although it allows the current implementation.
The server's identity may also be verified by comparing the reference identity to the Common Name (CN) [LDAP-SCHEMA] value in the last Relative Distinguished Name (RDN) of the subject field of the server's certificate (where "last" refers to the DER-encoded order, not the order of presentation in a string representation of DER- encoded data). This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed. Although the use of the Common Name value is existing practice, it is deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead. Note that the TLS implementation may represent DNs in certificates according to X.500 or other conventions. For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right- to-left convention.
It starts out by recommending for LDAP
The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types are matched in different ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of various subjectAltName types.
Am I correctly analyzing that compliance with this requirement to fence off man in the middle attacks is actually delegated to the ssl implementation, whereas it's openldap that chooses to extracts the authc_id from the peer's CN exclusively for SASL authentication?
Am I correctly inducing therefor, that OpenLDAP would happly acquire any CN string and present it as SASL's authc_id, more so since RFC 6125 states:
The following topics are out of scope for this specification: o Client or end-user identities.
If my speculations are correct, I'd like to invalidate this report.