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.
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
