All, I should have noted during public discussion that GTS was seeking enablement of both the websites and the email trust bits for the roots involved. I am re-opening public comment for another week until October 6 to gather any comments about this aspect of GTS' request. Thanks, Ben
On Fri, Sep 17, 2021 at 9:30 AM Brett L <[email protected]> wrote: > Hi Andrew, > > Thank you for your question and for asking for clarification. We have > provided an update to https://bugzilla.mozilla.org/show_bug.cgi?id=1729097 > that we hope addresses your question. > We have also started a new discussion on this list about how to better > handle the synchronization between CA software and CPSes, since delays have > occurred in the past for others in the ecosystem. You can see that thread > at > https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/BFk3q1R5gbM > . > > Brett L > Google Trust Services > On Thursday, September 16, 2021 at 12:58:05 PM UTC-4 [email protected] > wrote: > >> 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%2B1gtaY2w6XRDJMPpyRCfqZh9iVatbYeusR5BkD%3D%3Dm_nwicGXA%40mail.gmail.com.
