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.
On Tue, Apr 1, 2025 at 12:32 PM 'Aaron Gable' via CCADB Public < [email protected]> wrote: > 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. > > > On Tue, Apr 1, 2025, 08:20 'Amir Omidi (aaomidi)' via CCADB Public < > [email protected]> wrote: > >> 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 >> <https://groups.google.com/a/ccadb.org/d/msgid/public/1760a375-039d-47e9-8bb5-e5a05b7d28afn%40ccadb.org?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAEmnErez62LfyZxsOu44BtZnb088Q7mvnTtKJ7yv%3DZi%2Bb0QmFQ%40mail.gmail.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/CAEmnErez62LfyZxsOu44BtZnb088Q7mvnTtKJ7yv%3DZi%2Bb0QmFQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAFK%3DoS9VeVpwgqhdquqwk%2BX2Ms6Y3bSPw-95UADuZwWOBA3fDg%40mail.gmail.com.
