It appears that Grant Taylor via NANOG <[email protected]> said: >> It is my impression that the normal way to manage client certs is for >> the organization that runs the servers to sign and distribute certs >> to the clients. This isn't new. > >If you have multiple servers on the Internet that MUST use a public CA >for various unassociated clients to trust the certificate and you want >to leverage a certificate for communications between the two servers, >then Occam's Razor / Parsimony would state that you use the simpler / >one solution. ....
I would have thought this was obvious but apparently not: The point of a private CA is that you know the people whose certificates you're signing. If I run a mail system, I only sign the certs for my own users and I check who they are before signing. When someone presents a certificate, that cert includes not only the identity of the certificate itself, but also of the signer(s). So in my mail system, when a mail client presents a cert, if I see that my signature is on it I know it's one of my users. Even better, I can trust the identity info in the cert because I know I checked it when I signed it. And even better than that, I can sign whatever I want so the identity can include an email address or other user identity, not just a domain. Needless to say, random public CAs don't do that. A few of them used to sign mail address certs for S/MIME but none do now (at least not for free), and anyway if it doesn't have my private CA's signature, I don't know if it's one of my users or not. The security model for TLS always assumed that different signers would sign different things for different reasons. If you're using DANE to check your certs, for example, the TLSA record can have usage 3 to match the cert's own domain, or usage 0 to match the CA so you can use the TLSA record to validate everything you signed. It's a failure of the model that for too many purposes there's a big blob of public CAs which make only cursory identity checks and all of which are considered equivalent. R's, John _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/VM6BUP7RJWAMT6C5R7EPIM7NPW67X2TS/
