Bugzilla

I don't know why we're trying to act like which root program was spoken to is some major secret. [Comment 7](https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c7) already made it very clear that DigiCert have had conversations with the Chrome Root Program. The Chrome Root Program are also very clear that the ~70 certificates impacted by the TRO, and "several major DigiCert customers" require explanations if they went into delayed revocation. This also what is required by the Mozilla Root Store Program, and we've discussed this part to death. Even in [Comment 41](https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c41) DigiCert quotes the requirement that:
>When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis. 

What has been lacking are any explanations beyond the TRO. We'll put those ~70 certs aside and instead focus on the 83k other certs that should have been revoked in 24h and instead got pushed to 5 days and still lack the most basic required information. The Lessons Learned in [Comment 11](https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c11) is pertinent in my opinion:
>The industry needs a better notification process . Some customers thought the email notification was phishing. Others claimed not to receive it. We added banner messaging to the system, but not all customers logged into their accounts during the 5-day period, and those that did not missed the banner message.

This tells me that a large portion of customers did not respond at all, and that DigiCert took this lack of response as implied exceptional circumstances during this incident. Could DigiCert confirm if this presumption reflect reality? How will DigiCert handle a non-response going forward?

We're trying to find some way forward so that if this happens again, bar the TRO, revocations actually occur as required under the baseline requirements. This kind of discussion requires admitting that a fault has occurred somewhere in your practices for any remedy to be created.

Let us not forget that in the legal weeds of ~70 certs being legally barred from revocation, ~83k others were intentionally left alone. We need action items to show how this will not happen again. To date we only have one action item, implementing ARI, but I see no comment even mentioning that work being complete. We're approaching 3 months past its due date. The response to this incident has been a mess to be frank and an updated report trying to clarify DigiCert's ongoing actions would be beneficial.

It should not take 7 months of persistent questioning to get the barest of information out of a CA.

I don't know why we're trying to act like which root program was spoken to is some major secret. [Comment 7](https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c7) already made it very clear that DigiCert have had conversations with the Chrome Root Program. The Chrome Root Program are also very clear that the ~70 certificates impacted by the TRO, and "several major DigiCert customers" require explanations if they went into delayed revocation. This is also what is required by the Mozilla Root Store Program, and we've discussed this part to death. Even in [Comment 41](https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c41) DigiCert quotes the requirement that:
>When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis. 

What has been lacking are any explanations beyond the TRO. We'll put those ~70 certs aside and instead focus on the 83k other certs that should have been revoked in 24h and instead got pushed to 5 days and still lack the most basic required information. The Lessons Learned in [Comment 11](https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c11) is pertinent in my opinion:
>The industry needs a better notification process . Some customers thought the email notification was phishing. Others claimed not to receive it. We added banner messaging to the system, but not all customers logged into their accounts during the 5-day period, and those that did not missed the banner message.

This tells me that a large portion of customers did not respond at all, and that DigiCert took this lack of response as implied exceptional circumstances during this incident. Could DigiCert confirm if this presumption reflects reality? How will DigiCert handle a non-response going forward?

We're trying to find some way forward so that if this happens again, bar the TRO, revocations actually occur as required under the baseline requirements. This kind of discussion requires admitting that a fault has occurred somewhere in your practices for any remedy to be created.

Let us not forget that in the legal weeds of ~70 certs being legally barred from revocation, ~83k others were intentionally left alone. We need action items to show how this will not happen again. To date we only have one action item, implementing ARI, but I see no comment even mentioning that work being complete. We're approaching 3 months past its due date. The response to this incident has been a mess to be frank and an updated report trying to clarify DigiCert's ongoing actions would be beneficial.

It should not take 7 months of persistent questioning to get the barest of information out of a CA.