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 <http://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]
<mailto:dev-security-policy%[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/b3583e12-b6df-455b-9d20-342c401b91fa%40gmail.com.
