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/CACsn0cntu-BuUB9pnpxmdSJoKopsJWT8kzsyqes3ehR0pVXKVQ%40mail.gmail.com.
