[Discussion] Revocation timelines when CAA is violated

[Ryan Dickson]

Hi all,

We were curious for community feedback on the applicability of TLS BR revocation timelines when a publicly-trusted CA Owner has violated CAA expectations.

Studying CAA-related incident reports disclosed to Bugzilla over the past ~5 years, it appears there might be mixed interpretations of the required revocation timelines when CAA is violated. The evaluations below were based on a quick, non-comprehensive scan of CAA-related incident reports disclosed to Bugzilla, where we attempted to interpret the understood revocation timelines described in the incident reports based on observed revocation behavior, which wasn’t always clear.

• SSL.com: CAA Empty set handling results in Wildcard issuance (certificates revoked within 24 hours)

• SSL.com: Failure to process CAA records from one SubCA (certificates revoked within 24 hours)

• DigiCert: Unclear Disclosure of CAA Issuer Domain Names (certificates revoked within 5 days)

• GoDaddy: CAA checks passed when records contained incorrect variants of godaddy.com or starfieldtech.com] (certificates revoked within 5 days)

• GoDaddy: CAA checks did not properly handle issuewild tag allowing FQDN SANs to be added to wildcard certs (certificates revoked within 5 days)

• Google Trust Services: SXG certificates issued without correctly checking CAA restrictions (certificates revoked within 24 hours)

• Apple: TLS certificates issued outside the TTL of the CAA record (certificates revoked within 5 days)

• GlobalSign: Certificate issued to FQDN with malformed CAA (certificates revoked within 24 hours)

• Amazon Trust Services: Missing CAA Check For Test Website Certificates (certificates revoked within 24 hours)

• Let's Encrypt: CAA Rechecking bug (certificates revoked within 5 days)

From our view, it seems a 24-hour revocation window is more appropriate than a 5-day window. If CAA is to be interpreted as a security function explicitly enabled by a domain owner that is intended to prevent certificate issuance by unauthorized CAs, it feels odd to treat this differently than TLS BR 4.9.1.1 (2), which states “The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason #9, privilegeWithdrawn);”. We recognize that a request not being authorized and issuance not being authorized are indeed distinct, but from our view they appear to communicate the same conclusion in that from the subscriber’s perspective issuance should not have taken place.

We were hoping to collect opinions from this group to ultimately inform next steps, which might include clarifying expectations within the CA/Browser Forum TLS BRs.

As always, additional discussion is welcome and we’re open to changing our perspective.

Thanks for your consideration in participating in this discussion!

- Ryan, on behalf of the Chrome Root Program

[Amir Omidi (aaomidi)]

Thank you for putting this up CRP.

Based on the commentary I've seen through https://bugzilla.mozilla.org/show_bug.cgi?id=1951415, I do think that we should be treating violations that happen in the path of issuance as a misissuance that requires a 24 hour revocation window. I've always used, and interpreted CAA as a security measure. This is also asserted in the RFC itself: "CAA records assert a security policy that the holder of an FQDN wishes to be observed by Issuers."

> We recognize that a request not being authorized and issuance not being authorized are indeed distinct, but from our view they appear to communicate the same conclusion in that from the subscriber’s perspective issuance should not have taken place.

Agreed, I don't think reinterpreting this as anything else is useful for anyone (including the CAs). Having a unified approach to revocation simplifies operations by removing the judgement that is necessary today to ask "is this a 24 hour or 120 hour event?"

Cheers,

Amir

[Aaron Gable]

Thanks for bringing this conversation to a better venue!

For the record, I agree that failure to properly check CAA *should* result in a 24-hour revocation timeline. CAA checking is a critical, and easily automated, part of the issuance process.

However, I disagree that this is what the BRs actually say today.

A failure to conduct CAA does not fall under BRs 4.9.1.1(2), because the Subscriber has not notified the CA of anything. This is especially true in cases where the CA discovers that they have been failing to correctly check CAA, but it turns out that correctly checking CAA wouldn't have resulted in a different issuance decision.

And as I argued in the Bugzilla ticket, a failure to check CAA does not fall under BRs 4.9.1.1(5) because CAA is part of the issuance process, not part of the validation of domain authorization or control.

In that Bugzilla ticket, Amir said:

> From my interpretation of the BRs, domain issuance can be summed up as: "Always issue the certificate, except in ${list_of_scenarios}".

I strongly disagree with this interpretation. The BRs, in my opinion, say that a CA should *never* issue unless validation has succeeded. I think it is relevant and accurate to think of the BRs as first a positive filter (DCV, identity validation) that must be satisfied before a CA can even consider issuing, followed by a set of negative filters (caa, linting, mpic) that may still prevent issuance but could never allow issuance in the first place.

Amir also said:

> CAA (Certificate Authority Authorization) should be considered in the authorization part of domain authorization and control.

Unfortunately this interpretation is ahistorical. The "authorization" in CAA is about whether the CA is authorized to issue for the domain. The "authorization" in "domain authorization and control" is about whether the *applicant* is authorized to request issuance for the domain. These are fundamentally different things, despite using the same word.

Potential changes to the BRs that would resolve this apparent gap include:

- changing 4.9.1.1(2) to say "the CA learns that the request was not authorized", rather than requiring proactive notification (though this has the disadvantage that CAA failures now have two different revocation timelines, depending on whether the CA failure to check a record that happened to allow issuance vs one that happened to disallow it)

- changing 4.9.1.1(5) to list CAA alongside DCV

- adding a new list item to 4.9.1.1 explicitly addressing CAA

Aaron

P.S. apologies that this is likely my only contribution to this thread, as I leave for two weeks of vacation today.

--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/1760a375-039d-47e9-8bb5-e5a05b7d28afn%40ccadb.org.

[Jeremy Rowley]

I agree with Aaron. CAA failures should be treated as requiring a 24 hour revocation deadline, but the current language does not support this. We should fix it by changing 4.9.1.1 to include CAA checking failures as a reason for 24 hour revocation.  

To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAEmnErez62LfyZxsOu44BtZnb088Q7mvnTtKJ7yv%3DZi%2Bb0QmFQ%40mail.gmail.com.

[Ryan Dickson]

Hi all,

Thanks for the feedback.

We'll pursue this further within the SCWG. 

- Ryan