Control: tag -1 moreinfo Hi Moritz, thanks for the report.
On Fri, Jul 17, 2020 at 12:41:35PM +0200, Moritz Muehlenhoff wrote:
CVE-2020-15719 was assigned to an issue in OpenLDAP found by Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=1740070 The underlying OpenLDAP bug is restricted, though: https://bugs.openldap.org/show_bug.cgi?id=9266
The OpenLDAP ticket has now been made public.
The patch applied by Red Hat is https://git.centos.org/rpms/openldap/raw/67459960064be9d226d57c5f82aaba0929876813/f/SOURCES/openldap-tlso-dont-check-cn-when-bad-san.patch bug given that 1740070 is restricted I'm not sure if it affects the Debian OpenLDAP packages or not (as we sue GNUTLS instead of OpenSSL)
The patch was rejected upstream, with the explanation that the current behaviour already conforms to RFC 4513. I haven't checked, but would assume the GnuTLS implementation probably behaves the same way.
RFC 6125 § 1.4 "Applicability" notes:
This document also does not supersede the rules for verifying service identity provided in specifications for existing application protocols published prior to this document, such as those excerpted under Appendix B. However, the procedures described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so.
No such update has occurred for LDAP (that I'm aware of), so I think Howard is correct that RFC 4513 is still authoritative.
There might be an argument to be made that the Common Name matching is described as something the implementation "may also" do, so we could tweak how it works without actually violating RFC 4513. However it's enough of a grey area (and a subtle enough difference) that I think I'd prefer to just follow upstream, especially if some existing setups might be depending on that behaviour (CN not duplicated in a SAN).
What do you think?
