I suggest publishing what challenge was chosen by user (dns, http, tls-sni) in Certificate Transparency logs. This would make detecting and investigating misissued certificates much easier. For example, if I only use dns challenge and suddenly a certificate appears that was confirmed using http challenge I could be sure it wasn’t a legitimate certificate created by me. Also for dns challenge I would like it to include whether DNSSEC signature was present or valid.
Seems like CAA accounturi will probably address all of your attack scenarios without having to invent a new x.509 extension and blowing up the size of CT logs.
Not really. Maybe I don’t want to disable any challenges in case I want to use them later, or it’s not my website to begin with and I can’t modify its CAA records. The specific scenario I had in mind is that of domain that was previously signed using DNSSEC suddenly ceasing to have a signature.
But if it’s not your domain, you don’t control whether the domain registration has DNSSEC enabled.
FWIW CAA accounturi is about only allowing a certain ACME private key to issue certificates, not about disabling validation methods.
I mean if registrar stripped DNSSEC from the domain and changed the nameservers or something like that (.ru registrar did something like that if I remember correctly). Did not know about accounturi by the way.
Heh, can’t argue with that. I have a lambda task running that constantly makes observations of my domains in case my MX/NS/whatever records are suddenly changed by my registrar or DNS host. (Old version here, I rewrote it a while ago but don’t have a copy on me).
It would be a good idea to include the encountered DNSSEC key (if zone was indeed signed).