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. Brett L Google Trust Services On Friday, September 3, 2021 at 6:34:47 PM UTC-4 Brett L wrote: > 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 > > > On Thursday, September 2, 2021 at 11:07:27 AM UTC-4 Andrew Ayer wrote: > >> On Wed, 1 Sep 2021 14:21:47 -0700 (PDT) >> Brett L <[email protected]> wrote: >> >> > 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. >> >> The inaccurate CPS is a compliance violation, even if the DNS >> operator exception was not in use. >> >> This is the same basic scenario as >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1706967> - in that case, >> GTS' domain validation practices were compliant with the BRs, but GTS' >> CPS did not accurately reflect GTS' practices. >> >> It's troubling to see a recurrence of that scenario, and your email >> doesn't provide much of an explanation how this happened. >> >> 1. Why was the CPS change not published in May given that >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1706967> made clear the >> importance of having an accurate CPS? >> >> 2. When SC46 was merged into the BRs, did the automation described in >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1706967#c11> create an >> internal ticket for it? If not, why not? If it did, how did GTS respond >> to the ticket and why did the response not detect the CPS >> non-conformance? >> >> 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/775ab731-6ca7-493b-94c6-660d0f825106n%40mozilla.org.
