Hi all, Thanks for the feedback.
We'll pursue this further <https://github.com/cabforum/servercert/issues/580> within the SCWG. - Ryan On Wed, Apr 2, 2025 at 11:24 AM Jeremy Rowley <[email protected]> wrote: > 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/CADEW5O8LOE5m53Fem751LKaCFowZ8hvhiCVnoSOWUP1--9jTgw%40mail.gmail.com.
