On Sat, May 17, 2025 at 04:29:35PM +0200, Jaroslaw Rafa via mailop wrote:
> > Use cases vary, sometimes client certs are used to authenticate a
> > specific submission user, other times authorised client systems.
> > Regardless, while I the case for CAs to not issue combo client/server
> > certificates is not absolutely compelling, trusting public-CA-issued
> > client certs is ill-advised.
>
> Of course if I would implement cert auth, I would prefer to issue
> certificates to my users by my own CA; but if the public-issued cert would
> contain a *validated* email address as the subject, what speaks against
> using it for authentication as this (and only this) email user?
I posit that authentication of individual users by the usual WebPKI CAs
is much too weak to be meaningful. It is slightly better for individual
network hosts, but if the system is one which you have a sufficient
relationship to grant it non-default access, it is simplest to enroll a
dedicated public key as the relevant credential, just as you'd use an
SSH public key for logins, ... and not delegate that to any of a O(100)
CAs most of which you've never heard of.
Thus, while I am largely neutral on the reported change of policy, my
advice to server operations is to not rely on WebPKI public CAs for TLS
client auth used to grant restricted access. Configure a dedicated
keypair for each authorised client, or if you prefer a suitable SASL
credential (PLAIN, GSSAPI, ...).
--
Viktor.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
