Ben that aligns with my understanding of that requirement as well. I don’t think having the wrong version in the code is really the incident of interest in any of these issues. That’s an option for how to implement that requirement. I would be surprised if that’s the only way a CA knows they reviewed relevant BR changes and that their code correctly aligns with the requirements.
Aaron I generally agree but one way the version is relevant is that the validation methods aren’t self-contained. Most of them refer to other sections of the doc that can be updated without changing the method number. I do think it’s interesting that we are having two conversations about CP/CPS contents and how CAs describe they comply with the Baseline Requirements. Some of what we’ve discussed here I think overlaps the other discussion: https://groups.google.com/a/ccadb.org/g/public/c/iZg_253IZfo. Maybe one way we could make it more clear what the expectations are is to update the existing language From *“CAs SHALL maintain a record of which domain validation method, including relevant BR version number, they used to validate every domain.”* To something like *“CAs MUST maintain a record of which domain validation method they used to validate every domain. CAs MUST maintain a record that they have reviewed their implementation of domain validation each time the BRs updated to ensure it continues to meet the latest requirements."* On Thursday, February 19, 2026 at 3:22:34 PM UTC-8 Aaron Gable wrote: > Thank you, everyone, for the discussion here. This has been very helpful > and illuminating. I think I have one primary conclusion from the discussion > so far, and that conclusion leads to a follow-up question: > > Conclusion: It is not required that the CA's validation records contain an > explicit BR version number, as long as the CA can concretely and > reproducibly map each validation event to the version of the BRs validation > method that their processes implemented. Since validation methods are never > restricted without an effective date in the future, it should always be > possible for a CA to update their validation processes (and therefore the > "relevant BRs version number") between when the new version of the BRs is > published and when that validation method's new restrictions come into > effect. > > Question: In that case, what purpose does this requirement serve? Maybe > I'm being obtuse, but I fail to see how any mapping other than "the > validation was performed at time X, and BRs version Y was in effect at that > time" should ever matter. The CA is required to be in compliance with the > latest version of the BRs at all times. If a CA's validation processes no > longer comply with the current version of the BRs, that's a compliance > incident even if they are explicitly logging the fact that they comply with > some specific older version. > > My current feeling is that the BRs version number is not a meaningfully > useful part of the validation identifier, and that the BRs should be > updated to merely state that the CA must record the validation method used. > > Aaron > > On Thu, Feb 19, 2026 at 12:36 PM 'Ben Wilson' via [email protected] > <[email protected]> wrote: > >> Hi Ryan, Gurleen, Aaron, et al, >> >> Concerns about audit consistency are well taken. The compliance model >> works best when the trigger for action is objective and predictable, not >> dependent on individualized assessments by either CAs or auditors. >> >> I agree with Ryan that we should not create a regime where auditors must >> independently decide, revision by revision, whether a particular BR update >> was “substantively relevant” to a given DV method. That kind of subtle >> technical determination is unlikely to be applied uniformly. >> >> At the same time, I want to clarify what I was — and was not — suggesting. >> >> My main point was that, in my opinion, Section 3.2.2.4 was originally >> conceived to track adherence to the specific language governing each >> validation method, rather than to require mechanical synchronization with >> every new version of the TLS BRs where no changes were made to the >> applicable method. The requirement states that CAs “SHALL maintain a record >> of which domain validation method, including relevant BR version number, >> they used to validate every domain.” I read that as outcome-oriented: for >> each validation event, the CA must be able to determine which validation >> method and which BR version governed that validation. >> >> The text requires record-keeping but does not expressly prescribe the >> storage architecture, nor does it explicitly require that a literal BR >> version string appear in every transaction-level log entry, provided that >> the CA’s record-keeping system preserves a reliable and reproducible >> mapping to the governing BR version. In that sense, the core objective is >> traceability of the governing rule set — not publication-timestamp >> synchronization for its own sake. >> >> I think Gurleen’s and other’s operational concerns have force in a >> scenario where a new BR version introduces no changes to the applicable DV >> method, yet a strict interpretation would still require the CA to update >> its logging of BR version number immediately upon the new version becoming >> effective. In such case, logging changes would not correspond to any change >> in the deployed validation logic. >> >> Certainly, if a new BR version changed the validation method, that would >> be a different story. But where the deployed validation logic is >> current and traceable, and the only delta is the publication of a new >> version of the TLS BRs, I don’t think the intent of §3.2.2.4 was to require >> changes to validation systems and logging solely to track that publication >> event. >> >> Ultimately, I agree with Ryan on the principle that we want requirements >> that can be consistently implemented and verified, supported by language >> that reduces ambiguity and enables reliable CA oversight. However, if >> our intent is strict synchronization with each effective BR version >> regardless of method changes, we should state that clearly as a >> bright-line rule. And, if the intent is to ensure traceability of the >> governing validation logic, then that should likewise be stated more >> clearly. >> >> Thanks, >> Ben >> >> >> On Thu, Feb 19, 2026 at 12:35 PM Gurleen Grewal <[email protected]> >> wrote: >> >>> Thanks, Aaron, for initiating this discussion. You are correct that the >>> relevant requirement we planned to cite in our recent incident >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=2017747> is from section >>> 3.2.2.4 (and also section 3.2.2.5 for IP validation). While we are working >>> on a detailed report, we’ll offer some clarifications and thoughts relevant >>> to this thread: >>> >>> Our interpretation of BR Section 3.2.2.4 was mostly in line with Aaron’s >>> - that the log should reflect the BR version in effect at the time of >>> validation. Our incident report was filed because we discovered that the BR >>> versions we were recording were outdated. >>> >>> With the interpretation that Dexter gave, our situation might not have >>> been considered a reportable incident at all. >>> >>> We agree with the concerns raised, particularly under Aaron's >>> interpretation, that achieving instantaneous compliance the moment a new BR >>> version becomes effective is operationally very challenging. >>> >>> On Ryan’s interpretation - the issue is that the analysis and any >>> necessary code changes to comply with the substance of new BR requirements >>> must logically be completed before the effective date. However, the >>> separate act of changing the version number that is logged can only occur >>> at or after the new version becomes effective. >>> >>> This seems to imply that the mechanism for updating the logged BR >>> version string must be decoupled from other code rollouts related to >>> substantive BR changes. To meet a strict interpretation, a CA would likely >>> need an independent process to monitor for newly effective BR versions and >>> update a configuration value for the logging system, separate from regular >>> code deployment cycles. This is further complicated by typical rollout >>> schedules (e.g., weekly deployments) and potential production freezes, >>> which can easily introduce delays. >>> >>> Building and maintaining a system solely to ensure the logged BR version >>> string flips at the precise moment of effectiveness, detached from the >>> rollout of any actual logic changes, feels like it could become a >>> significant overhead. In our day-to-day operations, we have not felt the >>> need to query or filter validation data based on the BR version in force. >>> >>> We are very interested in the community's thoughts and suggestions on: >>> >>> >>> 1. >>> >>> How the Baseline Requirements could be clarified regarding the >>> expectations for logging the BR version, especially concerning the >>> timing >>> of updates. Is there an acceptable propagation delay? >>> 2. >>> >>> As Ben said: the forum has often chosen to obsolete prior validation >>> methods and introduce new method numbers when changes are made. Based on >>> this, should we consider dropping the requirement of keeping a record of >>> the version, and simply rely on the creation timestamp of the log entry >>> since CAs must always apply the current BR version anyway? >>> 3. >>> >>> A CA is expected to conform to its Certificate Policy and >>> Certification Practice Statements, which are versioned independently of >>> the >>> BRs; would it make more sense to version validations with the CP/CPS >>> versions in force instead of the BR versions? >>> >>> >>> We believe that the goal is to ensure audits can trace the rules >>> applied, and we hope to find a solution that is both effective and >>> implementable without excessive burden. >>> >>> Thanks, >>> Gurleen Grewal/Google Trust Services >>> On Thursday, February 19, 2026 at 10:02:30 AM UTC-8 Ben Wilson wrote: >>> >>>> Hi All, >>>> >>>> I would like to add a brief perspective to the discussion regarding >>>> Section 3.2.2.4 and the obligation to record the relevant BR version used >>>> for domain validation. >>>> >>>> My recollection of the original intent behind this provision was that >>>> the validation method number and the BR version number were meant to >>>> function together for identification of the validation method used. A >>>> validation method might evolve slightly while retaining the same method >>>> identifier, and the BR version number would provide additional precision >>>> about the exact rule set used for validation. In that sense, the BR >>>> version >>>> number was intended to complement the method number by identifying the >>>> governing text associated with that implementation. And it wasn't thought >>>> that CAs would revise domain validation code and logging processes every >>>> time a new version of the BRs was adopted. >>>> >>>> In practice, however, the Forum has often chosen to obsolete prior >>>> validation methods and introduce new method numbers when changes are made. >>>> As a result, the method identifier itself now typically captures the >>>> substantive change. That evolution in drafting practice arguably reduces >>>> the independent utility of the BR version number as a proxy for >>>> method-level differences. >>>> >>>> This is distinct from the MRSP obligation to conform to the latest >>>> version of the TLS BRs. If a new version introduces substantive changes to >>>> validation requirements, both implementation and recorded version must >>>> reflect those changes. That is not in dispute. >>>> >>>> The narrower question is whether Section 3.2.2.4 requires version >>>> recording to track the publication state of the consolidated BR document >>>> at >>>> a given moment in time, even where no changes were made to the applicable >>>> validation method and no implementation changes occurred. If ambiguity >>>> exists on that point, it may be useful to clarify the language >>>> prospectively to ensure auditability and consistent interpretation. >>>> >>>> I would be open to filing an MRSP GitHub issue to tighten our >>>> interpretation of Section 3.2.2.4 and, if appropriate, revise the MRSP >>>> language to ensure operational expectations are precise. The goal should >>>> be >>>> accurate record-keeping tied to governing validation logic, without >>>> creating unnecessary implementation churn where no substantive >>>> requirements >>>> have changed. >>>> >>>> Best regards, >>>> Ben >>>> >>>> On Thu, Feb 19, 2026 at 10:41 AM Ryan Hurst <[email protected]> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I think the operative word in Section 3.2.2.4 is "*used*." The >>>>> requirement is to record which BR version was used to validate every >>>>> domain, not which version happened to be current when the clock ran. >>>>> >>>>> *"Used" is an operational term*. It refers to the validation >>>>> procedure actually applied. If a CA performed validation under rules that >>>>> haven't changed between v2.2.2 and v2.2.3, it didn't use v2.2.3. It used >>>>> the version whose logic it implemented. >>>>> >>>>> The MRSP conformance obligation and the Section 3.2.2.4 recording >>>>> obligation are distinct. Conformance to the latest version means >>>>> deploying >>>>> its logic, and the log should reflect what logic ran. A CA that logs the >>>>> new version before deploying its logic is recording what it was supposed >>>>> to >>>>> conform to, not what actually ran. >>>>> >>>>> The corollary matters, though. A CA whose validation code hasn't been >>>>> updated to implement a new version cannot truthfully log that version. >>>>> Logging the current version when the code hasn't caught up is a false >>>>> record. It records what the CA was supposed to conform to, not what logic >>>>> actually ran. >>>>> >>>>> This interpretation is verifiable by an auditor, assuming a >>>>> functioning change management regime is in place. A CA whose stamps are >>>>> inconsistent with its deployment history has a substantive problem, not a >>>>> record-keeping one. >>>>> >>>>> Where I'd push back on Dexter's framing is on different grounds. >>>>> Recording an older version and arguing the validation was permissible >>>>> under >>>>> both isn't the same thing as recording the version you actually >>>>> implemented. The log should be a statement of fact about what governed >>>>> the >>>>> issuance, not a retroactive argument about compatibility with both >>>>> versions. >>>>> >>>>> The three incidents Aaron cited resolve differently under this >>>>> reading. If those CAs' validation logic hadn't been updated, that's both >>>>> a >>>>> substantive compliance failure under MRSP and a recording failure, two >>>>> distinct findings. If the logic was current but the version stamp wasn't, >>>>> that's a record-keeping error of a different character, and one the audit >>>>> record can help distinguish. >>>>> >>>>> The operational gap Aaron describes largely disappears once "used" is >>>>> understood as referring to deployed logic rather than clock time. The >>>>> remaining ambiguity around effective dates and timezones is a CA/BF >>>>> drafting problem worth fixing, and standardizing on UTC would largely >>>>> close >>>>> it. >>>>> >>>>> That said, a recording failure that stems solely from timezone >>>>> ambiguity in the effective date, where the underlying validation logic >>>>> was >>>>> current, seems the kind of thing that should be a note in an audit and >>>>> not >>>>> something that would cause someone to do a incident report or lose their >>>>> Webtrust seal. >>>>> >>>>> Thanks, Ryan >>>>> >>>>> On Wednesday, February 18, 2026 at 4:18:27 PM UTC-8 Dexter Castor >>>>> Döpping wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Regarding question #2: >>>>>> >>>>>> A CA must conform to the latest version version of the BRs, but I >>>>>> don't see anywhere that they aren't allowed to use the DV rules of older >>>>>> BRs and record this as the BR version. In this case the CA must make >>>>>> sure >>>>>> that what they're doing is allowed in both the old and new version of >>>>>> the >>>>>> BRs. >>>>>> >>>>>> Imagine version 1 allows CAs to do (A,B,*C*) and version 2 allows >>>>>> (A,B,*D*). >>>>>> >>>>>> If the records show that version 1 was used after version 2 was >>>>>> released, then they must not have done (C) or (D), but (A,B) would be >>>>>> fine. >>>>>> >>>>>> If the CA wants to start doing (D), then the CA system must be >>>>>> updated to record that version 2 of the BRs was used for DV. >>>>>> >>>>>> That's my interpretation at least. >>>>>> >>>>>> CA's should be aware of upcoming changes, and breaking changes often >>>>>> go into effect at a later date. E.g., (C) isn't outright removed, rather >>>>>> the BRs would say "Effective [future date] a CA MUST NOT do (C)". So I >>>>>> don't think that following a common subset of DV rules after a new BR >>>>>> release would be challenging. >>>>>> >>>>>> Technically a CA could stay on an ancient version of the BRs for DV >>>>>> requirements, it just wouldn't be a good idea because it becomes harder >>>>>> and >>>>>> harder to keep track of the common subset of requirements, and at some >>>>>> point it could even become impossible. E.g., version 1 says a CA MUST do >>>>>> (X) and version 101 says a CA MUST NOT do (X). So recording an old >>>>>> version >>>>>> of the BRs unnecessarily long would be a bad practice and isn't in the >>>>>> CA's >>>>>> interests. >>>>>> >>>>>> Regards, >>>>>> Dexter >>>>>> >>>>>> On 2026-02-19 00.30, 'Aaron Gable' via [email protected] >>>>>> wrote: >>>>>> >>>>>> I'd like to agree, but I'm not sure that's the case. The Mozilla >>>>>> Root Store Policy >>>>>> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/> >>>>>> says >>>>>> that CAs "MUST conform to the *latest version* of the CA/Browser >>>>>> Forum's TLS BRs" (emphasis mine). Performing validation in line with an >>>>>> older version of the BRs would be a violation of the MRSP, even if there >>>>>> is >>>>>> no difference for that particular validation method. >>>>>> >>>>>> Aaron >>>>>> >>>>>> On Wed, Feb 18, 2026 at 3:26 PM Watson Ladd <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Dear Aaron, >>>>>>> >>>>>>> I think this is premised on a misunderstanding of what I would think >>>>>>> the requirements are. The CA must record what version of the BRs was >>>>>>> used for validation. Let's say we go from version 1 to version 2 to >>>>>>> version 3. If Version 1 and version 2 don't contain any differences >>>>>>> relating to DV, then there is no problem. If 2 to 3 does, than the >>>>>>> requirement is that when the CA implements and deploys the new logic, >>>>>>> it records that it did so. The publication process of CABforum >>>>>>> documentation isn't I think linked to that transition. >>>>>>> >>>>>>> Sincerely, >>>>>>> Watson >>>>>>> >>>>>>> On Wed, Feb 18, 2026 at 3:21 PM 'Aaron Gable' via >>>>>>> [email protected] <[email protected]> >>>>>>> wrote: >>>>>>> > >>>>>>> > Hi all, >>>>>>> > >>>>>>> > I'd like to present two pieces of relevant context, and then ask a >>>>>>> few questions. Although this does somewhat concern CA/BF processes and >>>>>>> policies, I am sending this message to MDSP because it concerns a >>>>>>> question >>>>>>> of whether a particular action is a violation of the requirements, a >>>>>>> topic >>>>>>> upon which the CA/BF itself does not pass judgement. >>>>>>> > >>>>>>> > Context #1: >>>>>>> > >>>>>>> > In the past few weeks, three Bugzilla incidents have been opened >>>>>>> regarding recording the current version of the Baseline Requirements in >>>>>>> validation event audit logs: >>>>>>> > >>>>>>> > - Chunghwa Telecom: Domain validation records without the TLS BR >>>>>>> version >>>>>>> > - iTrusChina: Domain validation records without the TLS BR version >>>>>>> > - Google Trust Services: Outdated BR version in some validation >>>>>>> records >>>>>>> > >>>>>>> > The relevant requirement cited in the first two incidents (and I >>>>>>> suspect likely to be cited in the third incident's full report) is from >>>>>>> Section 3.2.2.4: >>>>>>> > >>>>>>> > > CAs SHALL maintain a record of which domain validation method, >>>>>>> including relevant BR version number, they used to validate every >>>>>>> domain. >>>>>>> > >>>>>>> > Context #2: >>>>>>> > >>>>>>> > The CA/BF has recently published several new versions of the >>>>>>> Baseline Requirements. For example: >>>>>>> > >>>>>>> > - SC-094, with an Effective Date of 2026-02-16, was merged at >>>>>>> 2026-02-16 21:06 UTC, and v2.2.3 was announced on the mailing list at >>>>>>> 2026-02-16 21:13 UTC >>>>>>> > - SC-096, with an Effective Date of 2026-02-17, was merged at >>>>>>> 2026-02-17 20:30 UTC, and v2.2.4 was announced on the mailing list at >>>>>>> 2026-02-17 20:36 UTC >>>>>>> > - Both new versions were merged to the website repo at 2026-02-18 >>>>>>> 03:40 UTC, and the website itself was updated about four minutes later >>>>>>> > >>>>>>> > Questions: >>>>>>> > >>>>>>> > 1. At what time does a new BRs version become effective? The BRs >>>>>>> themselves only give a date, not including a time nor a time zone. But >>>>>>> the >>>>>>> new version of the BRs is often not published until some portion of the >>>>>>> way >>>>>>> through that day (or the previous day, or the next day, depending on >>>>>>> time >>>>>>> zones). Does a new version become effective at midnight UTC on the date >>>>>>> given as the Effective Date within the document? Or when merged into >>>>>>> the >>>>>>> `main` branch of the github repo? When sent to the mailing list? When >>>>>>> published to the website? >>>>>>> > >>>>>>> > 2. Let's assume for the moment that a new BRs version becomes >>>>>>> effective when the email announcing it is sent to the mailing list. >>>>>>> Suppose >>>>>>> a validation is performed one second after that email is sent, and the >>>>>>> CA >>>>>>> records the previous Baseline Requirements version number. Is that a >>>>>>> violation of the requirement from Section 3.2.2.4? If yes, is there a >>>>>>> reasonable way for a CA to anticipate publication of a new BRs version >>>>>>> and >>>>>>> cease all validation activities until it is actually published? >>>>>>> > >>>>>>> > Thank you for your time and discussion, >>>>>>> > Aaron >>>>>>> > >>>>>>> > -- >>>>>>> > You received this message because you are subscribed to the Google >>>>>>> Groups "[email protected]" 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/mozilla.org/d/msgid/dev-security-policy/CAEmnErddD53vAnY896_kUrVcpPRFrGbP70xH0E550PVOmX1S%3Dg%40mail.gmail.com >>>>>>> . >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Astra mortemque praestare gradatim >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "[email protected]" 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/mozilla.org/d/msgid/dev-security-policy/CAEmnErcc_r7%3DuALuPfJbeQk%3D0k1XWcKYvM6NhTdmnQnFtcH6ew%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErcc_r7%3DuALuPfJbeQk%3D0k1XWcKYvM6NhTdmnQnFtcH6ew%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "[email protected]" 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/mozilla.org/d/msgid/dev-security-policy/cc3a4e0d-5483-444e-8b83-a25ed2290f0en%40mozilla.org >>>>> >>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/cc3a4e0d-5483-444e-8b83-a25ed2290f0en%40mozilla.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" 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/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaN8wRZQnqWp11t%2BjkmVaKayWcaTgaVUF5qjXp8mW52Bw%40mail.gmail.com >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaN8wRZQnqWp11t%2BjkmVaKayWcaTgaVUF5qjXp8mW52Bw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "[email protected]" 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/mozilla.org/d/msgid/dev-security-policy/ad2b2315-ccbb-4c1c-8eea-f2134f08f5f6n%40mozilla.org.
