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.
