okay, so, speaking of 4,
WebTrust CAs are an embarrassment in many ways but a _major_ problem is the absolute discarding of POLA. why on earth should eMudhra be able to sign every TLD on earth from a single busted-ass intermediate. It is way, way past time for AT LEAST intermediates to have *some* constraint on what they can sign
like yes this would still be a catastrophically bad incident if they could only sign e.g. "*.co.in" domains. but why do they have to be able to sign *.ca.us.
This whole system is based on falsified premises about who is able to handle key material and how. You should have to operate a CA that can only sign *.xyz for like ten years before getting the keys to *.com
@glyph we do have CAA records, although this is solving the problem from the other end
@glyph I'm not actually sure if a browser will consult a CAA record at all and now that I think about it I think the answer is no :S
Oct 22, 2026, 9:22 PM@whitequark @glyph only CAs are supoosed to check CAA records, so it doesn't protect against a bad CA or pwned key.
A good solution would be DANE (where you put your public key into a DNS record instead of relying on a CA) but so far I think no browser has added support for it. Both CAA and DANE checks would require reliable DNSSEC on end user devices.
Oct 22, 2026, 9:30 PM@whitequark @glyph yes, there are two ways off the top of my head:
1. Request all the DNSSEC data and verify locally
2. Ask your DoH resolver to do DNSSEC and trust your resolver
I don't think the first option is very common.
@jomo @whitequark I am kind of a DNSSEC hater (I think it fails for many of the same very good reasons that we collectively gave up on HPKP) but you could do more limited versions of this
@whitequark @jomo we have root CAs, just chain the signature up to one of them instead. we're already talking about modifying clients with a new protocol, so have a signed x509 assertion about what CA can be trusted for your domain, if you want that, and stick it in a DNS record. like an externally imposed EKU. you can cache really aggressively to ameliorate availability concerns
Oct 23, 2026, 11:10 AM@glyph @whitequark aren't you just sort of reinventing DANE here? And how do clients ensure the DNS record is authentic, if not DNSSEC?
@glyph not knowing an awful lot about specific of pki and such, I was wondering if we could imagine that DNS records might indicate what your allowed authority is or if that would create a chicken and egg issue or something.
Oct 22, 2026, 9:24 PM@ewjoachim @glyph you can do that right now and I wrote down some recommendations a while ago:
@jomo @glyph correct me if I’m wrong but CAA tell CAs not to issue a certificate to your domain if you told them not to, they’re not used by UAs to reject certificates issued by the wrong CA, no ? There’s CT but it’s only after the fact, and with CT you don’t need CAA to find a rogue certificate (though it helps automated detection at scale)
If I’m an attacker and I found a CA whose private key is 4, CAA won’t keep me from impersonating the domain, will it ?
Oct 23, 2026, 11:01 AM@ewjoachim @glyph yes, if you want client side validation there is DANE, see here:
@jomo @glyph correct me if I’m wrong, but DANE only helps this specific problem if UAs refuse certificates served through HTTP if a DANE record exists ? And the work necessary to make it so seems like it would be exactly as hard as adding the same constraint on UAs with CAA ? And no UA does it today ?