DNS CAA to be Mandatory from September 2017

The Vote

Back in March, the CA/Browser Forum (CABForum) held a vote for Ballot 187 - Make CAA Checking Mandatory. The vote passed with a resounding 19 out of 21 CAs voting 'yes' (one 'no' and one 'abstain') and all three participating browsers in favor [1]. The practical result of this is that starting September 8th of 2017 it will become mandatory for CAs to consult CAA records before issuing certificates. [2]

The Current State of the PKI Ecosystem  

A commonly lifted obstacle in PKI infrastructure is the issue of the Web of Trust. Through the years we've seen on several occasions how that trust can be violated, i.e when a CA goes rogue, becomes compromised, or fails to follow its own regulations. This was illustrated back in 2011 by the infamous breaches of the Comodo and DigiNotar certificate authorities where both CAs issued wildcard certificates for several high profile domains, or just this year when Google Chrome downgraded certificates issued by Symantec due them to issuing test certificates to Google domains without Google's knowledge. [3]

Several combined efforts have been made to solve the inherent vulnerabilities to this system. So far, no single solution is all encompassing, and even the overlap of every solution proposed doesn't create a foolproof system. Certificate Transparency [4] is one such effort, and has been been supported by EJBCA Enterprise since EJBCA 6.0.4, released in early 2014. [5]

So what is DNS CAA?

DNS Certificate Authority Authorization is defined in RFC 6488 [6] and defines a requirement for CAs to make a pre-issuance check, according to the certificate policy set, with a record stored at the DNS of the affected domain. Any CA without authorization from the DNS will be warned not to issue a certificate. 

Essentially, it allows the end client to restrict which CA's they consider trustworthy, and since the vote at CABForum, this implies any CA not enforcing CAA. While this does not guard against CAs going rogue (by ignoring CAA), it allows domain owners to restrict issuance to CAs whose security and policies they trust, and to exclude less trustworthy (but still CAA enforcing) CAs from the web of trust. 

How does this affect EJBCA?

Here at PrimeKey we more than welcome any efforts to improve the state of the PKI ecosystem, so naturally we were delighted to see the results of the vote at CABForum. While CAA hasn't been a priority for us until now (due to little demand), we've moved up our roadmap. Thus we've slated CAA for EJBCA 6.9.0, which will be released to by August 4th 2017, a month before CAA becomes mandatory. CAA will be an Enterprise feature only

On behalf of the EJBCA Development Team, 

Mike Agrenius Kushner,

Product Owner EJBCA

[1] https://cabforum.org/pipermail/public/2017-March/009988.html
[2] https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/
[3] https://arstechnica.com/security/2017/03/google-takes-symantec-to-the-woodshed-for-mis-issuing-30000-https-certs/
[4] https://www.certificate-transparency.org/
[5] http://blog.ejbca.org/2014/06/certificate-transparency-with-ejbca.html
[6] https://tools.ietf.org/html/rfc6844