1

CAA, or Certificate Authority Authorization, provides a way to designate which CAs are allowed to create a Certificate for specific domains. This is done accomplished by publishing new caa DNS records, with three directives: issue issuewild iodef. For example:

 $  dig craigslist.org caa
craigslist.org.         300     IN      CAA     0 issue "digicert.com"
craigslist.org.         300     IN      CAA     0 iodef "mailto:security@craigslist.org"
                                               -^-

The 0 value in the record indicates the Flags for the record. At the moment, only two values are defined:

0 - Understanding this CAA record is optional 128 - Understanding this CAA record is critical

RFC 6844 specifies this regarding the Critical flag:

   Flags:  One octet containing the following fields:

      Bit 0, Issuer Critical Flag:  If the value is set to '1', the
         critical flag is asserted and the property MUST be understood
         if the CAA record is to be correctly processed by a certificate
         issuer.

         A Certification Authority MUST NOT issue certificates for any
         Domain that contains a CAA critical property for an unknown or
         unsupported property tag that for which the issuer critical
         flag is set.

And earlier provides this as an example:

   The critical flag is intended to permit future versions CAA to
   introduce new semantics that MUST be understood for correct
   processing of the record, preventing conforming CAs that do not
   recognize the new semantics from issuing certificates for the
   indicated domains.

   In the following example, the property 'tbs' is flagged as critical.
   Neither the example.net CA nor any other issuer is authorized to
   issue under either policy unless the processing rules for the 'tbs'
   property tag are understood.

   $ORIGIN example.com
   .       CAA 0 issue "ca.example.net; policy=ev"
   .       CAA 128 tbs "Unknown"

In all my browsing around, I've only see the flag set to 0 ... with one exception:

 $  dig stackoverflow.com caa
stackoverflow.com.      300     IN      CAA     0 issue "digicert.com"
stackoverflow.com.      300     IN      CAA     0 issue "letsencrypt.org"
stackoverflow.com.      300     IN      CAA     0 issuewild "digitcert.com"
stackoverflow.com.      300     IN      CAA     0 issuewild "letsencrypt.org"
stackoverflow.com.      300     IN      CAA     128 iodef "mailto:sysadmin-team@stackoverflow.com"
                                               -^^^-

The iodef directive has a flag of 128.

Presumably, what this means is if a CA (not specified in the issue or issuewild directives) is asked to create a certificate for "stackoverflow.com" and does not understand the iodef record, they MUST NOT create the certificate.

But if they do not understand iodef, they likely do not understand issue and issuewild (as all 3 are specified in the original CAA RFC. Which means they are likely to just issue the certificate.

If they DO understand the CAA RFC, then they understand all three directives, and would send the violation e-mail either way.

If Stackoverflow had set all of their CAA records to 128, I wouldn't have thought much of it. But the fact that only the iodef record has the critical flag turned on confused me. What benefit is there to turning on the critical flag on just the iodef record, but not issue or issuewild ?


To avoid this being speculative, I just want to clarify my question is not "Why did Stackoverflow choose to this". Instead, it is a generic "Why would anyone choose to do this, i.e., what is the purpose of this"

2
  • 1
    Is obeying the CAA RFC required by CABF BAs? – Z.T. Apr 8 at 18:54
  • 1
    @Z.T. As far as I know, yes. (assuming we are speaking of the same thing). This is where CABF approves CAA. This is where they made checking CAA records mandatory. Quote from this last link: When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 6844. And this is where they slightly change the wording of RFC 6844 – Eddie Apr 8 at 22:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.