https://bugs.openldap.org/show_bug.cgi?id=10149
--- Comment #7 from [email protected] <[email protected]> --- (In reply to Ondřej Kuzník from comment #5) > would you be able to explain in more detail what this provides that > cannot be achieved with existing options like LDAP_OPT_X_TLS_CACERT, > ...? The existing options are routed firmly in the 1990s, a time when keys and certificates were files on disk. In the 2020s, keys and certificates exist in secure enclaves, such as TPM chips, smartcards (physical or virtual), or Hardware Security Modules. The location of these certificates is no longer described with a filename or a directory on disk, but are instead described by a URI. These URIs have been standardised, for example this RFC for URIs starting with pkcs11: https://www.rfc-editor.org/rfc/rfc7512.html OpenSSL has been updated in OpenSSL3 to use a new provider framework that is URI based. This replaces the old ENGINE mechanism. What this patch does is offer a clean, safe, no-legacy-baggage, mechanism to access keys and certificates described by a URI. In the long term it is expected that all prior options be deprecated. > Also if you want to open a MR on git.openldap.org, that would make > review much easier for all involved but we don't insist on going that > route. If you need your Gitlab account to be confirmed, please provide > your account name here (and make sure its email matches your Bugzilla > email). Will do. > > Is there an option to have this included in the v2.6.x branch? > > As a significant change in library API, I feel it unlikely to land in > 2.6 unless it can be shown that it has no impact on existing > installations. This patch isn't a change, but rather an addition. Instead of changing existing behaviour, we add two new constants with clean, well defined semantics for the new way of accessing certs and keys. This will have no impact on existing installations because no existing installations have been changed. The driver for this patch is the 389ds directory server. Originally, 389ds was developed against the NSS security library, which has the ability to store keys and certificates in smartcards and HSMs. At some point a number of years ago 389ds secure replication was updated to replace mozldap+nss with openldap+openssl. This created a regression - openldap+openssl did not have the ability to access smartcards or HSMs, so a hack was introduced where 389ds did a rudimentary attempt to export a certificate and key as files in a temporary directory for use by openldap+openssl, and the this was released mid-product-cycle on a number of distros. Bang, production outage, pain and suffering. This patch brings openldap+openssl into the world of openssl providers, and allows 389ds to replicate securely using keys and certificates in smartcards and HSMs. Once this patch is in place and once the 389ds patch is in place, nine years of LDAP replication pain will go away. -- You are receiving this mail because: You are on the CC list for the issue.
