On Thu, Feb 19, 2026, 11:52 AM 'Gurleen Grewal' via [email protected] <[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. > I don't think that's correct. Your code will through some mechanism change the validation behavior at some time t. At that time it can change the logging as well to match. > > 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/dc3ee31e-299e-452c-a516-be3b19b2e8bdn%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/dc3ee31e-299e-452c-a516-be3b19b2e8bdn%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/CACsn0ckz4K%2B3OFv%2BWkKteaSZqPSAERHf28LEfdAc6%3DwJE56hfw%40mail.gmail.com.
