(In reply to Dathan Demone from comment #5)
Ryan, in one of your previous comments, you stated that there is a non-zero time to determine if there is a miss-issuance and the 5-day revocation counter starts after that.
In this case, we had to ensure that there was a miss-issuance as we had 2 parties associated with the same account (the government organization and their sub-contractor).
That comment is saying quite the opposite - that the revocation timer does not begin when you notify the customer, as was inappropriately claimed in that issue, but when the issue is determined. I think it's useful to highlight, in that it demonstrates a pattern of Entrust having trouble implementing core requirements in a manner consistent with other CAs and broader expectations.
This understanding of the word "notification" to refer to when the subscriber was notified, as opposed to when Entrust is notified, is based on the immediately preceding answer by Entrust, stating that "The Subscriber of the certificate was notified".
The response, by Bruce, seems to further confirm this shared understanding, as it's based on the CA obtaining evidence - that is, prior to the investigation beginning, prior to the investigation completing, and prior to the notification (if any) to the Subscriber. As one can see throughout Section 220.127.116.11, the action taken is generally the moment the CA is made aware of an event or is notified of an event, which would precede many investigations and focus on when the CA first obtained the evidence; thus ensuring expeditious incident handling.
As it relates to the timelines of incident response, the CA should endeavor to notify programs as soon as possible, as per https://wiki.mozilla.org/CA/Responding_To_An_Incident . With respect to revocation delays, the advice is to notify prior to the expiration of the BR-mandated period (24 hours or 5 days).
we will work to shorten this timeframe in the future.
The nature of the specific questions in Comment #2 are to help understand how this happened, so that it can be clear how the steps being proposed to achieve this shortening would have meaningfully helped.
Thus, it's still useful to understand the specific answers to those questions, just as it is to understand why the delay between March 8 to March 11.
A useful example is to more concretely and comprehensively detail your incident response procedures, handling both internal and external reports. Understanding how Entrust Datacard handles incidents, and how this response aligned or did not align with those procedures, can help understand what steps are being taken in the future.
This is similar to the desire to understand the basis for delaying revocation and how mitigations are being placed for the future, as per Comment #4.
If Entrust Datacard believes its processes reflect best practice, and this was merely an unfortunate exception, then sharing those best practices helps ensure the entire ecosystem improve, while also providing feedback that might highlight unaddressed gaps. Similarly, if Entrust Datacard is concerned there may be a systemic issue at play, providing a deeper analysis about the existing procedures may help identify those flaws, and allow others to share successful best practices being used.