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%2B1gtaZta-J7VRw%2BK7GTgk4dZ7LKebpi21FvHc6RAh7g-wyStA%40mail.gmail.com.
