On Mar 31, 2026, at 8:00 PM, David Adrian <[email protected]> wrote: > Speaking for the Chrome Root Program [1], the policy does not introduce a > blanket prohibition on all CAs from issuing TLS certificates containing both > clientAuth and serverAuth EKUs. Rather, after March 15, 2027, the Chrome Root > Store will, by default, only include anchors representing serverAuth-only > hierarchies.
i.e. in theory, client certs aren't forbidden. In practice, they are. > This does not preclude CAs from: > - Continuing to issue from hierarchies that may be trusted elsewhere > - Issuing clientAuth certificates from a new hierarchy What alternate hierarchies are there? i.e. not just theoretical ones, or ones specific to an SDO. But ones which by default come with all end-user systems. And, are marked with id-kp-FOO as being fit for a particular purpose. > Nothing also stops non-Chrome clients from altering the content of their > trust stores to trust CAs relevant to their use case. That's always been the case. That isn't the issue. The issue is that those CAs are either (a) SDO specific, or (b) private to an organization. If I want to use TLS with non-WWW protocols on the Internet, how am I supposed to do that? I've brought this point up before, and the answer is always the same. "Get a WWW certifcate, and use that. Oh, and in case the CA gets upset about that usage, lie to them about your use-case." If you search crt.sh for certificates, you'll find CAs using WWW certificates for many non-WWW purposes. So even the CAs don't believe their own rhetoric about mis-use of WWW certs. > History has taught us that commingling PKI use cases causes more harm than > good. It is a consistent security problem when PKI hierarchies intended for > public web sites get entangled in non-web use cases. Since it is (in practice) impossible to get public certs for non-WWW uses, people just use WWW certs. It's not useful to claim that there's a security problem when everyone does it. In practice, the WWW CA hierarchy has become the *only* public internet CA hierarchy. The people have spoken. This dichotomy between theory and practice is a security problem that's much worse than any alleged issue with using WWW certs in a non-WWW context. I can't use other certs, because the CAs won't issue them. The CAs then claim that there are problems with using WWW certs in that way, all the while doing what they forbid others to do. So I find the statements of "just use something else" to be disingenuous. It's not useful to tell people "you must do A not B", all the while preventing them from doing A, and doing B yourself. That behavior tends to annoy people. What needs to happen is that there needs to be a new CA hierarchy which is allowed to issue non-WWW certs. And, those CAs have to be shipped in the root stores of all end-user machines. And, the certificates have to be just as easy to get as WWW certs. But the CAs show little interest in doing this. The OS vendors show little interest in doing this. So the users are stuck with using WWW certs for non-WWW purposes. Because the WWW people have forced everyone to do that. Can we please either fix the issue, or stop pretending that the WWW CA hierarchy is WWW only? Alan DeKok.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
