https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #8 from sean@teletech.com.au --- (In reply to sean from comment #7)
it would be hard completely remove it.
Thinking more about this. I see in RFC4513 Section 4: "Upon initial establishment of the LDAP session, the session has an anonymous authorization identity."
I also note that LDAPS has never been formally standardized. One can only speculate about allowing an initial (non-anonymous) identity by some future LDAPS standard. (RFC4513 specifies StartTLS and IPSEC, but not Implict TLS). I note from RFC4513 section 1 "LDAP may also be protected by means outside the LDAP protocol". They must have been aware of LDAPS and chosen not to include it for some reason.
Tangential... This continues a general preference seen in the RFC's towards explicit TLS. I personally consider "explicit TLS" to be a strategic mistake by the standards making bodies. Back in the day when they were thinking "We can't waste ports having a separate plain and encrypted port", they should have said security comes first! If people want unencrypted, they can negotiate a null cypher.
Back on topic... LDAP V3 does not require a "bind" operation. One could imagine a very nice and clean arrangement where a client connects with a client TLS certificate and immediately starts work (without the bind). The TLS server just taking the client's identity from the client's certificate. Unfortunately, just a pipe dream at the moment.