On August 25, 2021, we began a three-week public discussion[1] on GTS’ request to replace 5 GTS root CA certificates.[2] (Step 4 of the Mozilla Root Store CA Application Process[3]).
*Summary of Discussion and Completion of Action Items [Application Process, Steps 5-8]:* On 31-Aug-2021, Andrew Ayer noted that the DNS operator exception to performing CAA had been eliminated by Ballot SC46 of the CA/Browser Forum (passed on 2021-06-02 and effective on 2021-07-12), but that it had not been removed from GTS' CPS until 2021-08-11.[4] GTS responded that it had removed the option to use the DNS operator exception from its CA platform in May 2021, but acknowledged that it had not published its updated CPS until August--because it was including the SC46 update as part of more comprehensive CPS update and manual review-and-approval processes took longer than expected. As a result, GTS opened up a bug in Bugzilla, #1729097[5], and filed an incident report to explain that the above processes had resulted in the delay in publishing an updated CPS. In the bug, GTS has agreed to: (a) update its processes to require that a tracking bug for compliance documentation revisions include a machine-parseable publication deadline related to the effective date of any requirements changes (and require that tracking bugs be linked to any related software changes); (b) implement, by Friday, 2021-09-17, a proactive alert of impending deadlines for documentation updates; and (c) double-check, by 2021-09-24, all ballots since SC3, and to ensure that all required changes have been made and are accurately reflected in its CPS.[6] I believe these remediation steps are adequate and can be implemented relatively easily. I also believe they address Andrew’s concerns that GTS might continue to bundle CP/CPS changes into an annual review and not ensure that its CPS would remain up-to-date with its actual policies and practices. Any further discussion on this issue can take place in Bug #1729097. *Close of Public Discussion and Intent to Approve **[Application Process, Steps 9-10]:* GTS seeks only to replace existing CA certificates, and I conclude that in this circumstance, public discussion does not need to be placed on hold or extended further. Thus, this is notice that I am closing public discussion (Application Process, Step 9) and that it is Mozilla’s intent to approve GTS’ request to replace these five CA certificates (Step 10). This begins a 7-day “last call” period for any final objections. Thanks, Ben [1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/lAu1_S48RAA/m/vVnldsU4BAAJ [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1675821 [3] https://wiki.mozilla.org/CA/Application_Process [4] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/lAu1_S48RAA/m/p-51xlT5BQAJ [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1729097 [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1729097#c1 On Mon, Sep 13, 2021 at 9:21 AM Andrew Ayer <[email protected]> wrote: > On Fri, 3 Sep 2021 15:34:47 -0700 (PDT) > Brett L <[email protected]> wrote: > > > Though we always try to land documentation changes with corresponding > > code changes sometimes it is simply not always feasible. > > The above statement is concerning, because section 2.2 of the Baseline > Requirements state: > > "Section 4.2 of a CA's Certificate Policy and/or Certification Practice > Statement SHALL state the CA's policy or practice on processing CAA > Records for Fully-Qualified Domain Names; that policy shall be consistent > with these Requirements." > > If a CA doesn't update their CP/CPS at the same time as deploying > changes to their CAA policy, they will be out of compliance with the > Baseline Requirements, as GTS was for 90 days. > > I was expecting the incident response in > https://bugzilla.mozilla.org/show_bug.cgi?id=1729097 to address > the problem by providing a solution for ensuring GTS' CP/CPS remain > up-to-date with GTS' actual policies and practices. Instead, GTS's > response is to ensure CPS changes are published by the time of the > compliance deadline that motivated the change. This would not have > prevented GTS' non-compliance, just limited it to 60 days. (It would, > however, have prevented their non-compliance from being externally > detectable.) > > GTS' response also won't address CP/CPS changes that aren't motivated > by BR/MRSP changes, such as adding another CAA Issuer Domain Name. > It appears that with GTS' current process for CP/CPS changes, such a > change could be delayed by up to a year if it gets "bundled" with GTS' > next annual CPS update. To reiterate, this would be a violation of BR > section 2.2. What is GTS doing to make it feasible for them to comply > with this requirement moving forward? > > Regards, > Andrew > > -- > 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 on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20210913112012.dfd4bf784a3f58d2a45f2172%40andrewayer.name > . > -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaahKaFjC-fgNpc_WM3qawj%3D9FY%3DqWmvKR7nb%2Bx2%2Bh6Nkw%40mail.gmail.com.
