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.
