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.
