On 28/06/2023 11:59 pm, Quanah Gibson-Mount wrote:
I guess it comes to an issue of trust. I wouldn't trust Amazon, Facebook, or Google issued certificates, and I personally avoid making use of those types of integrations for username/password.
It's really hard to avoid depending on and putting some trust in third parties in computing. You say I shouldn't trust a public CA but I should trust you (OpenLDAP). The CA and OpenLDAP are both third parties to me. There is no clear winner here, and in fact, denying adopters of your software the option of choosing the CA just looks suspicious. Obviously, by using OpenLDAP, I choose to trust it's authors and by extending this trust to OpenLDAP I gain convenience. There is always a tradeoff - risk versus reward. This is my tradeoff to make, as the risk is mine and not OpenLDAP's.
By choosing to trust a public CA (a not unprecedented or unreasonable thing to do) I gain the convenience of using off-the-shelf software without burdensome installation and management overhead.
If the public CA betrays my trust and issues certificates for my domain to someone else, the system is immediately compromised. That is not OpenLDAP's fault and that risk would be present regardless of whatever trust paradigm OpenLDAP uses. Using the public CA for OpenLDAP authentication does not add to my overall risk and I believe it is a perfectly reasonable thing to do.
I am not suggesting, every user of OpenLDAP should make the same decisions I have done. Just that OpenLDAP should acknowledge the validity of my decisions and consider supporting this use case by offering a mechanism restrict the names on publicly issued client certificates.