CAA Mandated by CA/Browser Forum

Certification Authority Authorization (CAA), specified in RFC 6844 in 2013, is a proposal to improve the strength of the PKI ecosystem with a new control to restrict which CAs can issue certificates for a particular domain name. Although CAA had been in the proposed-standard state for more than 4 years, there was little obvious happening until very recently, with only a hundred or two hundred sites adopting it. But that’s going to change, because the CA/Browser Forum recently voted to mandate CAA support as part of its certificate issuance standard Baseline Requirements. The changes will become effective in September 2017.

The fact that any CA can issue a certificate for any domain name is commonly cited as the weakest aspect of the PKI ecosystem. Although CAs want to do the right thing, there are no technical controls that prevent them from doing whatever they chose to do. That’s why we say that the PKI ecosystem is a weak as the weakest link. With hundreds of CAs, there are potentially many weak links.

CAA creates a DNS mechanism that enables domain name owners to whitelist CAs that are allowed to issue certificates for their hostnames. It operates via a new DNS resource record (RR) called CAA (type 257). Owners can restrict certificate issuance by specifying zero or more CAs; if a CA is allowed to issue a certificate, their own hostname will be in the DNS record. For example, this is what someone’s CAA configuration could be (in the zone file):

example.org. CAA 128 issue "letsencrypt.org"

And that’s all there is to it. Before issuing a certificate, CAs are expected to check the DNS record and refuse issuance unless they find themselves on the whitelist. In addition to the “issue” directive from the example, two other directives are supported: “issuewild” that restricts issuance of wildcard certificates, and “iodef”, which provides support for notification in the cases something goes wrong. (In case you’re wondering, the number “128” is a flags byte with its highest bit set, meaning the directive use is considered critical and must be followed.)

At a high level, CAA has similar purpose to public key pinning (HPKP), but the implementation is entirely different. First, CAA prevents certificate issuance whereas HPKP is a run-time client-side control that prevents already-issued certificates from being seen as valid. In other words, CAA is for CAs, HPKP is for browsers. HPKP, which works by whitelisting public keys, is a strong technical control; in contrast CAA is largely an administrative control. While it’s expected that CAs will automatically check CAA before issuing certificates, what happens next is somewhat vague—they switch to manual processing and may end up issuing the certificate if they believe that the request is genuine. The main weakness of CAA compared to HPKP is that there are many CAs and that they all need to implement the checks correctly, as well as resist social engineering attacks when CAA is violated.

But this is not to say that CAA is useless, or inferior to HPKP. That’s because of the advantages, the main being that, unlike HPKP, which is potentially very dangerous, it’s not possible to abuse CAA and bring down a web property. Whereas HPKP can kill your business if you mess up, CAA will merely annoy you. In the end, one way to look at CAA is “public key pinning for normal web properties”, who would find HPKP to complicated and scary to use.

In case you’re wondering, SSL Labs already supports checking for CAA. You can see it in the report for google.com, for example. (It’s in the top section, along with the information on the key and first certificate.)

Tags