Hi all, We were curious for community feedback on the applicability of TLS BR revocation timelines <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#4911-reasons-for-revoking-a-subscriber-certificate> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1932973> (certificates revoked within 24 hours) - SSL.com: Failure to process CAA records from one SubCA <https://bugzilla.mozilla.org/show_bug.cgi?id=1938236> (certificates revoked within 24 hours) - DigiCert: Unclear Disclosure of CAA Issuer Domain Names <https://bugzilla.mozilla.org/show_bug.cgi?id=1914911> (certificates revoked within 5 days) - GoDaddy: CAA checks passed when records contained incorrect variants of godaddy.com or starfieldtech.com <https://bugzilla.mozilla.org/show_bug.cgi?id=1904749>] (certificates revoked within 5 days) - GoDaddy: CAA checks did not properly handle issuewild tag allowing FQDN SANs to be added to wildcard certs <https://bugzilla.mozilla.org/show_bug.cgi?id=1904748> (certificates revoked within 5 days) - Google Trust Services: SXG certificates issued without correctly checking CAA restrictions <https://bugzilla.mozilla.org/show_bug.cgi?id=1902670> (certificates revoked within 24 hours) - Apple: TLS certificates issued outside the TTL of the CAA record <https://bugzilla.mozilla.org/show_bug.cgi?id=1841534> (certificates revoked within 5 days) - GlobalSign: Certificate issued to FQDN with malformed CAA <https://bugzilla.mozilla.org/show_bug.cgi?id=1759854> (certificates revoked within 24 hours) - Amazon Trust Services: Missing CAA Check For Test Website Certificates <https://bugzilla.mozilla.org/show_bug.cgi?id=1746945> (certificates revoked within 24 hours) - Let's Encrypt: CAA Rechecking bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1619047> (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 -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/CADEW5O-W1YWgPtgkF2_Cg1Zpu3c%3DK1qVf_jSzx04RL3%2BfchrNw%40mail.gmail.com.
