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 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 ?