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.