Hello OpenLDAP community,
There have been a number of inquiries recently in regards to RFC 6125 and its support in OpenLDAP. After reviewing the contents of RFC 6125, we felt it important to publicly address the OpenLDAP project's stance on this RFC.
RFC 6125 specifically states it does not supersede existing RFCs. Certificate handling for the LDAP protocol is defined in RFC4513, thus the procedures defined in RFC 6125 do not apply to the LDAP protocol. Additionally, RFC 6125 explicitly excludes the LDAP protocol from consideration in Section 1.4 and Appendix B.3.
Even without the specific exclusions for the LDAP protocol, the OpenLDAP project considers the general concepts in RFC 6125 as harmful. It redefines the purpose of subjectAlternativeName from being an alternative to the commonName to being the only allowable source for consideration unless it is not present in the certificate. This breaks standard practice for commonName going back to at least 1998. Additionally it breaks standard wildcard certs as issued from various Certificate Authorities as the long standing behavior has been to use a commonName=*.example.com, which is not allowed with RFC 6125.
The Subject Naming discussion in Section 2.3 and 2.3.1 is also problematic. Rather than clarify the confusion around Distinguished Names, it just muddles things even further. This is a simple concept and there's no good reason to perpetuate the confusion: DNs are hierarchical names, just like DNS names are hierarchical names. A fully qualified name is an ordered concatenation of names from a root of a naming hierarchy to its leaves.
In DNS the root is "." and the names are written in leaf-to-root order, thus: com example.com www.example.com
LDAP software has adopted this same leaf-to-root order for its string representation of DNs, thus: dc=com dc=example,dc=com dc=www,dc=example,dc=com
Although older X.500 software tended to use a root-to-leaf ordering, just like filesystems use, and older X.509 certificate tools used this as well: /dc=com /dc=com/dc=example /dc=com/dc=example/dc=www
This is still the exact same DN, just using a different convention for string representation.
Ignoring the fact that DNs are hierarchical, and noting that a CN appearing anywhere in the DN can be used to check a service name, flies in the face of over 30 years of practice.
In summary, RFC 6125 breaks long-established practices for weakly supported reasons and fails to enhance understanding of the subject.