Fix #194 - Add CAA test

[mxsasha]

• This should be updated after Switch to simple stub resolver for DNS lookups #1378 is merged, it'll clean up the code a bit.
• Climb tree, stop if relevant 'CAA RRset' is found, do not check root (.)
• Parse the actual record
• Limit max records processed (1000)
• Code cleanup/review
• API update
• Release notes
• Create empty or stub content labels @mxsasha, mark issue as content & release blocker
• Fill content labels @baknu / @bwbroersma

https://caatestsuite.com/ has useful test cases.

Key references:

• RFC8659 DNS Certification Authority Authorization (CAA) Resource Record, particularly chapter 4
• RFC8657 Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding, specifically chapter 4
• IANA Certification Authority Restriction Properties registry
• IANA ACME Validation Methods registry (referred from RFC8657)

[bwbroersma]

Should check at least syntax, although maybe CAA even protects if it's invalid?

• Optional extra test (could also be a new ticket, but it's already mentioned Test domains for CAA record [website test] #194 ): ℹ️ notify if CAA is non-empty but RFC 8657 / acme-caa¹ accounturi is not present? At least LetsEncrypt supports it and it's discussed at the CA/Browser Forum.

Regarding the Let's Encrypt IP certificates I notices this comment:

CAA in rDNS is a possibility, but has some challenges with how CAA "tree climbing" works, especially for IPv6. There was an IETF LAMPS draft a while ago using that idea, and it's possible that design work could continue.

But this is not a problem, since internet.nl does not allow checking of ip address resources, only host names.

¹ RFC 8657 - Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding

[mxsasha]

This is progressing well. The experiment of using ABNF as a basis for the parser is good and we should keep doing this. It just reduces errors and manual work. The error message in case of a mismatch with the grammar will point the user to the character, so they have something to go on.

Current implementation

• We retrieve all CAA records for the domain under test, further up the tree if needed.
• If there are no CAA records, the rest result is bad.
• We parse all CAA records. If any have a format error, the test result is bad.
• Otherwise, the test result is good.

The tech table displays translatable messages in a similar way as securitytxt - you can see them in the updated translations files for now. We have a message for having found a CAA (and on which domain), for not found, and specific error messages where possible.

Rationale for bad test result on parse errors

Some areas of CAA are fail-mostly-secure. If someone messes up their issue property, they probably just can't get certificates. That would typically lead to loud errors from either certificate expiration monitoring or, failing that, actual expiry. Much preferred to an unauthorised certificate being issued somewhere. Therefore, I'd prefer people configure
a bad issue than none. However, for properties like iodef this does not apply: if you misconfigure it, you miss out on reporting, which creates a risk. Therefore, we should not allow misconfigured iodef - they indicate that the user may be assuming that they get reports, but won't. Let's be consistent and just require correct syntax.

Second argument: the first argument is about security, but we're not a security tool, we are a standards compliance tool. Misconfigured CAAs are not standards compliant, therefore we must not accept them.

Next questions for us to decide

1. What should our requirements be, other than the current "have 1 or more CAA records, which pass a syntax check"? Should we require at least an issue*? Or at least issue or issuewild?
2. Email addresses are mentioned for the iodef and contactemail properties. For iodef, there is no definition of what an email address is. For contactemail, the spec refers to RFC6532 section 3.2, which is actually a patch on the grammar from two previous RFCs. It was starting to get complicated. Both checks at this time accept anything with an @.
3. This is currently under certificate tests, both in the job scheduling and frontend, but it doesn't fit: all those other tasks are run once for each web server IP. CAA is on a domain level. Maybe it fits better under DNSSEC? The only category that evaluates the domain. Other than for email, where authenticity does the same.
4. Do we want separate content for web and mail? E.g. explain the need for CAA differently, or the meaning of a bad verdict? I feel it's excessive, web and mail can use the same explanation.
5. How detailed do we want to get in error messages? Currently we do not distinguish whether iodef value is invalid because it's an FTP URL, or an HTTPS URL without a netloc. I think that level of granularity is out of our scope. The translations file diffs show which error messages we have now.
6. Should we follow errata 7139? Current status is "reported". I am leaning to yes, as it makes things clearer.

[mxsasha]

Discussion from meeting:

• we should require issue and perhaps also issuewild.
• For email syntax, see what we do for DMARC. Does urlparse check email address?
• For accounturi/validationmethods we stick to validating syntax. We do not require it, until we start doing it ourselves.
• For mail we should actually look at MX hostnames for the domain.
• For web, try to keep it under certs in the UI, but run the test once per domain.
• This means slightly separate content for web and mail.
• We are implementing errata 7139 as it is only a label change.