This is to announce the beginning of the public discussion phase for Google Trust Services' (GTS) request to replace five existing root CA certificates with ones that were re-signed last year, August 13, 2020. See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9).
The five roots are as follows: GTS Root R1, GTS Root R2, GTS Root R3, GTS Root R4, and the GlobalSign ECC Root CA - R4. (A sixth root CA certificate, the GlobalSign Root CA - R2, was re-signed using SHA1, and so I have removed it from this inclusion request.) The reason for their replacement is that the original CA certificates do not contain the digitalSignature key usage bit, which is required for direct OCSP signing by the CA. (See https://bugzilla.mozilla.org/show_bug.cgi?id=1652581)
GTS’ request has been tracked in the CCADB and in Bugzilla as follows:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000666
https://bugzilla.mozilla.org/show_bug.cgi?id=1675821
Mozilla is considering approving GTS’ request. This email begins a 3-week comment period, after which, if no concerns are raised, we will close the discussion and the request may proceed with steps required to replace the certificates in question.
Root Certificate Information:
GTS Root R1
https://crt.sh/?q=D947432ABDE7B7FA90FC2E6B59101B1280E0E1C7E4E40FA3C6887FFF57A7F4CF
Download – https://pki.goog/repo/certs/gtsr1.pem
Replaces https://crt.sh/?id=139646520
GTS Root R2
https://crt.sh/?q=8D25CD97229DBF70356BDA4EB3CC734031E24CF00FAFCFD32DC76EB5841C7EA8
Download – https://pki.goog/repo/certs/gtsr2.pem
Replaces https://crt.sh/?id=139646522
GTS Root R3
https://crt.sh/?q=34D8A73EE208D9BCDB0D956520934B4E40E69482596E8B6F73C8426B010A6F48
Download – https://pki.goog/repo/certs/gtsr3.pem
Replaces https://crt.sh/?id=139646519
GTS Root R4
https://crt.sh/?q=349DFA4058C5E263123B398AE795573C4E1313C83FE68F93556CD5E8031B3C7D
Download – https://pki.goog/repo/certs/gtsr4.pem
Replaces https://crt.sh/?id=139646525
GlobalSign ECC Root CA - R4
https://crt.sh/?q=B085D70B964F191A73E4AF0D54AE7A0E07AAFDAF9B71DD0862138AB7325A24A2
Download – https://pki.goog/repo/certs/gsr4.pem
Replaces https://crt.sh/?id=8644166
CP/CPS:
Current CPS is Version 4.0 / August 11, 2021
https://pki.goog/repo/cps/4.0/GTS-CPS.pdf
Repository location: https://pki.goog/
Audits:
GTS’s WebTrust auditor is Ernst & Young, and the most recent audit reports are dated November 2, 2020. These may be downloaded by clicking on the WebTrust seals on GTS’s repository page. The WebTrust Baseline Requirements audit noted the following four incidents (closed):
1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1630040 (OCSP responder issue)
2 - https://bugzilla.mozilla.org/show_bug.cgi?id=1652581 (digitalSignature KeyUsage not set – which gave rise to this inclusion request)
3 - https://bugzilla.mozilla.org/show_bug.cgi?id=1625498 (tracking possible audit delay)
4 - https://bugzilla.mozilla.org/show_bug.cgi?id=1667844 (certificates not disclosed in CCADB)
Other Incidents (Closed):
5 - https://bugzilla.mozilla.org/show_bug.cgi?id=1678183 (invalid ASN.1 encoding in OCSP response)
6 - https://bugzilla.mozilla.org/show_bug.cgi?id=1706967 (CPS stated outdated DV method from BR 3.2.2.4.10)
7 - https://bugzilla.mozilla.org/show_bug.cgi?id=1708516 (delayed incident updates)
8 - https://bugzilla.mozilla.org/show_bug.cgi?id=1709223 (SHA1 signing of GlobalSign Root CA - R2)
9 - https://bugzilla.mozilla.org/show_bug.cgi?id=1715421 (delayed revocation of end entity certificate)
Thus, this email begins a three-week public discussion period, which I’m scheduling to close on or about 15-September-2021.
A representative of GTS must promptly respond directly in the discussion thread to all questions that are posted.
Sincerely yours,
Ben Wilson
Mozilla Root Program
Hi Andrew,
Thank you for the questions and checking on details.
We removed the option to use the DNS operator exception from our secondary CA platform on 2021-05-13 (60 days before the ballot changes went into effect, see timeline below). Our primary CA platform has never used it.
In May, we conducted our annual CPS review and prepared several updates including the one that removed the exception from Section 4.2.4. It was not published earlier because the update was bundled together with other changes in one revision.
We did not file an incident because removal of the DNS operator exception was identified and acted upon well ahead of the deadline. The CPS update was also started before SC46 became effective. We regret it was not published prior to the effective date.
Timeline
2021-04-29 - Engineers are made aware of need to remove the operator exception
2021-05-04 - Code changes removing the exception from CA systems where it was allowed are proposed
2021-05-05 - CPS edits are proposed to remove the DNS Operator exception as required by SC46
2021-05-13 - Code change becomes effective and use of the operator exception is technically restricted by all of our systems
2021-07-12 - SC46 becomes effective
2021-08-11 - The GTS CPS covering removal of the operator exception is publicly published
Brett L
Google Trust Services
Hi Andrew,
As mentioned earlier the CPS update including this change was not published earlier because the update was bundled together with the annual CP/CPS update. As you know, GTS also had multiple incidents open around the time of these changes, so we were engaging a number of additional partner teams and stakeholders for reviews with the goal of ensuring we covered all updates and improvements in one pass. Wider participation in the update helped highlight additional areas to simplify and clarify language, but this also took additional time to complete.
We flagged SC46 as an action item on 2021-04-09 and the change to our CPS was made in draft form a few days later (2021-05-13). Though the automation in question was in active development at the time, it was not completed. When SC46 was published a few weeks later (2021-06-02), the review process for requirement changes identified it as having been addressed because at the time both the associated code changes had been deployed and the CPS was in the process of being approved for release.
Though we always try to land documentation changes with corresponding code changes sometimes it is simply not always feasible. That being said upon review we feel the 30 day delay that was introduced as a result of the bundling of other changes together is too long and have now filed an incident report 1729097 to capture this event.
As for https://bugzilla.mozilla.org/show_bug.cgi?id=1706967 it was different in a few ways. The first is that Mozilla Root Store Policy under section 2.2 (3) has a clear expectation that "The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with." In that particular case, the CPS included a forbidden validation method. Additionally we had missed that the change in numbering had not been reflected in our CPS. In this case, the changes to remove the operator exception were complete, the documentation was in progress and our tracking and automation tooling covered both. The second difference is that 4.9.1.1.7 obligated us to revoke the certificate because although our practices were conformant with current regulations, the CPS no longer had a reference to an allowed domain control verification scheme.
Brett L
Google Trust Services
Hi Andrew,
While preparing our incident report, we reviewed all previous communications and noticed a small typo in our previous message. The SC46 action item was flagged on 2021-04-29, rather than 2021-04-09.
We apologize for any confusion this may have caused.
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
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20210913112012.dfd4bf784a3f58d2a45f2172%40andrewayer.name.
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.