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 <https://datatracker.ietf.org/doc/html/rfc8659#section-5> 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 On Tuesday, April 1, 2025 at 11:02:07 AM UTC-4 Ryan Dickson wrote: > 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/1760a375-039d-47e9-8bb5-e5a05b7d28afn%40ccadb.org.
