CAA is NOT checked by browsers, the BRs do not say browsers should check CAA, and indeed it is specifically NOT designed to be checked by RPs at all. CAA tells the Issuers (Certificate Authorities) whether the name owner authorises them to issue at a moment in time.
If you think "that seems useless" it's probably because you completely misunderstood the security model it's written for. We don't want untrustworthy or incompetent CAs at all, this is not a guard against those. This is a guard against trustworthy, competent CAs that you've got your own reasons to disallow for your specific names.
Example: Facebook for years had a single preferred CA and their contract with that CA said everything gets signed off by the certificates team. After Let's Encrypt came on the scene a subcontractor developing example.facebook.com needed HTTPS, didn't read all the paperwork from Facebook and just got a cert from Let's Encrypt. Facebook security freaked out because their team hadn't authorised this weird new certificate. Let's Encrypt did nothing wrong, but it looked exactly like an attack. CAA lets Facebook tell every CA except the one that knows about their internal policy, "Thanks, but no thanks". Let's Encrypt would have checked CAA and told the subcontractor "Sorry, no, policy forbids, check CAA" and when they went to Facebook to ask why they'd have got an earful for not obeying policy.
And if a non-authorized CA ignores it and creates a cert anyway, that cert will still work. It's basically a kind of robots.txt file for CAs.
I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.
It turns out that making someone's job easier is in fact the foundation of good security.
One way this is true is that people won't use security if it isn't usable or easy to use. For almost two decades we had CA workflows that sucked. Certificate use has spiked in the last couple of years. Why? Witness the outstanding work by LetsEncrypt which is now allowing Chrome to flag insecure login forms.
Other examples; DDoS defense as a service, facial recognition that unlocks your phone every time you pick it up, cars that lock when driving, and fobs that make passwords almost irrelevant.
Good security and making someone's job easier are one and the same.
No, it's still about security, in a defense-in-depth sense. Even if your trusting CA's in this context they all count as attack surface: CAA helps minimize it. For example, it's possible that a CA's validation process has a flaw. A CAA record may isolate you from that.
Even the "corporate policies" is a security thing, not "making someone's job easier". Presumably Facebook handles their certificates carefully: if any engineer could obtain certificates the odds that they would and that the certificates would be passed around in email attachments is 100%.
Speaking of defense-in-depth. I don't understand why do certificates released by public CAs not add an extension to the cert if the cert was given to a DNSSEC validated host.
As browsers are unwilling to validate DNSSEC directly it would allow browsers to just check the certificate. This could be complemented with a relevant HTTP header that forces the browser to only accept the certificate if it has been given out to DNSSEC validated host.
> I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.
Pretty much the best attempt at this I've seen is the Certificate Transparency thing designed by Google and implemented in Let's Encrypt and a few other CAs. Having a public, auditable log of every certificate officially issued could can be used to validate certs, Chrome enforces this with new EV certs and Symantec certs.
We still have to depend on CAs to 'follow the rules', and the client has to support it (does your mail client verify Cert Transparency? does your backend microservice?) and be connected to the Internet, and Google, etc.
There are better ways to handle it, I think, but they may involve changing how we both sign and verify certs.
More specifically: Log servers can be shown either a normal X.509 certificate or a "pre-certificate" which is proof that a Certificate Authority intends or intended to issue some particular certificate. Right now these are actually X.509 certs that were "poisoned" to make them useless, but in future they will probably be some other format.
Anyway, when shown a new certificate or pre-certificate, the log server gives you a Signed Certificate Timestamp proving when it saw the document.
Chrome (and eventually Safari and Firefox) require suitable SCTs when shown any modern public certificate or they may conclude the certificate should not exist and fail the connection or mark it insecure, or even report it to Google/ Apple/ Mozilla for investigation.
SCTs get to the browser in one of three ways:
1. Most popular. The site's CA made pre-certificates, logged those, got back SCTs and baked the SCTs inside the real certificate. This changes nothing for a site operator, if you use Let's Encrypt and have never heard of SCTs, don't worry, all your current Let's Encrypt certs are done this way.
2. Less popular: The CA doesn't put SCTs inside the certificate, but it DOES staple them inside OCSP responses. Then you staple an OCSP response into your certificate responses and everything works.
3. Also less popular: The SCTs go in a separate TLS extension when a client connects, saying "Hey, I want SCTs" and they get them back only if they ask for them.
And if it is a publicly trusted CA, it now gets to explain to browser and OS vendors how it managed to fail to comply with a required policy. (although there's of course difficulty in proving that a DNS entry existed)
Hi, am author. Ah, yea, I know that CAs are supposed to check CAA before issuing and I do understand the security model. Figured browsers could/should too, but just dug a bit more and you’re right that CAA is explicitly not supposed to be checked by RPs.
Conceptually I don’t see any major problem with using CAA for this purpose though, at least for your own internal PKI. The only potential issue is that if you change your CAA record your issued certs would break, so there’s an availability attack.
I just found a reference to another standard called DANE that’s supposed to do this, but I don’t know anything about it.
CAA is NOT checked by browsers, the BRs do not say browsers should check CAA, and indeed it is specifically NOT designed to be checked by RPs at all. CAA tells the Issuers (Certificate Authorities) whether the name owner authorises them to issue at a moment in time.
If you think "that seems useless" it's probably because you completely misunderstood the security model it's written for. We don't want untrustworthy or incompetent CAs at all, this is not a guard against those. This is a guard against trustworthy, competent CAs that you've got your own reasons to disallow for your specific names.
Example: Facebook for years had a single preferred CA and their contract with that CA said everything gets signed off by the certificates team. After Let's Encrypt came on the scene a subcontractor developing example.facebook.com needed HTTPS, didn't read all the paperwork from Facebook and just got a cert from Let's Encrypt. Facebook security freaked out because their team hadn't authorised this weird new certificate. Let's Encrypt did nothing wrong, but it looked exactly like an attack. CAA lets Facebook tell every CA except the one that knows about their internal policy, "Thanks, but no thanks". Let's Encrypt would have checked CAA and told the subcontractor "Sorry, no, policy forbids, check CAA" and when they went to Facebook to ask why they'd have got an earful for not obeying policy.