4 ms·
The magic sauce would be CAA. This is under the assumption that all publicly trusted CAs respect CAA and have no bypass bugs (CAs probably aren't ... too far of
by pfg 8y ago
The magic sauce would be CAA. This is under the assumption that all publicly trusted CAs respect CAA and have no bypass bugs (CAs probably aren't ... too far off target) and that they properly validate DNSSEC (good luck with that, I don't think there's even consensus on what the Baseline Requirements consider compliant).
Anyway, in this mostly hypothetical world where all of that works as intended, you could use a CAA record with just one or two CAs with which you have some kind of contractual relationship requiring out-of-band verification. Alternatively (and, IMO, preferable, since the controls are technical), you can use the ACME CAA extension[1] to lock down the validation methods to just DNS-based ones, or bind the the whole validation flow to a key. Let's Encrypt is working on this currently[2].
[1]: https://tools.ietf.org/html/draft-ietf-acme-caa-05#section-4 https://tools.ietf.org/html/draft-ietf-acme-caa-05#section-4
[2]: https://community.letsencrypt.org/t/acme-caa-validationmethods-support/63125 https://community.letsencrypt.org/t/acme-caa-validationmetho...
- tptacek 8y agoMy understanding is (a) the current interpretation of the BR's does not require DNSSEC, and that (b) validation of DNSSEC among CAs is not the norm; CAs have disabled it because it proved unreliable.
- pfg 8y agoIt's certainly not an interpretation I'd punish a CA for, the language in section 3.2.2.8 is rather ambiguous. Let's Encrypt is running a fail-close setup for DNSSEC, so I wouldn't quite say it's too unreliable in this particular context. Still, it's quite clear that DNSSEC's complexity is getting in the way of things here. A solution just for this specific use-case would be much simpler overall, and I'm not buying into any of the other benefits DNSSEC claims to bring, so I'd rather just see it die.