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.
