|
Top-level
 The 'flags' field should be exactly either 0 or 128: the "Issuer Critical Flag" is bit 0 of the flags field, and not the _value_ of this field. Unsurprisingly, many people get that wrong (with values encountered ranging from 0 to 250, with no clear indication what people might think those values mean): 21 comments
Ignoring misspelled records ("issiue", "issuewld", "iodev", ...), here are the CAA records by tag: The 'iodef' property can have one of three methods: mailto, http, and https. Extra l33t points go to kyhwana.org for putting a log4j canary into their CAA record. The most frequently 'iodef' records are shown here. Pretty pleased to see Yahoo's records dominate, since setting the right CAA policy and adding default CAA records for all of Yahoo's (many) parked domains was something I pushed for at my time there. Yay! \o/ But let's see what CAs everybody is authorizing via their 'issue' and 'issuewild' records. In total, I found almost 2,200 distinct 'issue' records (for domains in all TLDs, 456 distinct for the Top 1M domains) and 878 'issuewild' records (all TLDs, 227 Top 1M). Here are the top 20 CAs: But... let's carefully read RFC8659 again. The 'issue' tag grants "authorization to issue certificates containing that FQDN to _the holder of the issuer-domain-name or a party acting under the explicit authority of the holder of the issuer-domain-name_." Who is the "holder of the issuer-domain-name" for, say, geotrust.com, rapidssl.com, or thawte.com? That's right: DigiCert. So by specifying 'geotrust.com' in your CAA record, you are implicitly also granting the various DigiCert subsidiaries authorization, which really isn't obvious at all. If we then add up the various related CA domains, our breakdown looks more like this: Or, if you prefer Pareto charts to better illustrate the cumulative concentration: Authorizing a given CA can still be too broad for your taste, which is why RFC8657 specifies the 'accounturi' and 'validationmethods' parameter extensions. There's also a draft extension for Signed HTTP Exchanges ('cansignhttpexchanges') that appears to only be supported by DigiCert and pki.goog. The usage of these parameters is quite limited: In conclusion, after analyzing around 214 million domain names for CAA records, the following are worth noting: 1) CAA records are still not widely used. Across all TLDs, only 1.4% of domains use CAA records; out of the Top 1M Domains, only 4.8%. Considering that CAA records have been around since 2010 and honoring them has been mandatory for CAs since 2017, this seems like a pretty poor adoption rate. 2) Most people don't set 'iodef'. Those domains that do use CAA records tend to use the 'issue' and 'issuewild' records, but only minuscule fraction (0.9% of all TLDs' domains; 3.2% of the Top 1M Domains) set 'iodef'. 3) Extensions are not widely used. The dominance of the 'cansignhttpexchanges' parameter here surprised me, but could be explained by being pushed without industry agreement by Google as part of their "Accelerated Mobile Pages" (AMP) framework? And finally, and most importantly: 4) A small number of CAs dominate. Only 7 Certificate Authorities account for over 99% of all CAA 'issue'/'issuewild' records (10 CAs for 99% of the Top 1M Domains). 3 alone account for over 75%: Comodo, DigiCert, and Let's Encrypt. Even though this only covers the small percentage of domains that do set CAA records, I would not be surprised if the overall use of CAs across all domains followed a similar -- and similarly centralized -- distribution. (In some markets, regional players will play a bigger role; once again the inability to get access to all ccTLD zones makes this difficult to assess.) So no, you probably could replace your giant trust bundle with fewer than... 20 or so root CA certs and not notice a difference, I'd guess. But whether that's a good thing, whether it's wise for the entire internet to place all -- well, >99% -- of its certificates/eggs into fewer than 10 CAs/baskets seems more than questionable. And that's it for today - thanks for playing "Whose Cert Is It Anyway?" โ๏ธ This thread is available as a blog post here: P.S.: This was the third blog post in a series on the centralization of the internet. Part 1, covering NS records, can be found here: Or, as a Twitter thread: Part 2, covering MX records, can be found here: Or as a Mastodon thread: |
Gregory's Server
RFC8659 defines three different properties: 'issue', 'issuewild', and 'iodef'. That's it.
(CA/B Forum Ballots SC13 and SC14 added 'contactemail' and 'contactphone', but those aren't part of the RFC, and I only encountered 741 and 23 uses of these respectively, so let's ignore them.)