Bug 1619179 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Josh: Thanks for the update.

While this is understandably complex, and I appreciate the level of detail in Comment #3, I want to highlight that it's missing **essential** details as covered in the [expectations for Responding to an incident](https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation)

Relevant bits from that section are included below for emphasis:
>  The rationale must include an explanation for why the situation is exceptional. Responses similar to “we deem this misissuance not to be a security risk” are not acceptable.
> Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a **clear timeline describing if and when the problematic certificates will be revoked or expire naturally**, and supported by the rationale to delay revocation.
> That you will perform an analysis to determine the factors that prevented timely revocation of the certificates, and **include a set of remediation actions in the final incident report that aim to prevent future revocation delays.**

It may be helpful to review some of the [still open](https://wiki.mozilla.org/CA/Incident_Dashboard#Revocation_Delays) reports from some CAs, as well as some of the [past incidents](https://wiki.mozilla.org/CA/Closed_Incidents#Delayed_Revocation)
Josh: Thanks for the update.

While this is understandably complex, and I appreciate the level of detail in Comment #3, I want to highlight that it's missing **essential** details as covered in the [expectations for Responding to an incident](https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation)

Relevant bits from that section are included below for emphasis:
>  * The rationale must include an explanation for why the situation is exceptional. Responses similar to “we deem this misissuance not to be a security risk” are not acceptable.
> * Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a **clear timeline describing if and when the problematic certificates will be revoked or expire naturally**, and supported by the rationale to delay revocation.
> * That you will perform an analysis to determine the factors that prevented timely revocation of the certificates, and **include a set of remediation actions in the final incident report that aim to prevent future revocation delays.**

It may be helpful to review some of the [still open](https://wiki.mozilla.org/CA/Incident_Dashboard#Revocation_Delays) reports from some CAs, as well as some of the [past incidents](https://wiki.mozilla.org/CA/Closed_Incidents#Delayed_Revocation)
Josh: Thanks for the update.

While this is understandably complex, and I appreciate the level of detail in Comment #3, I want to highlight that it's missing **essential** details as covered in the [expectations for Responding to an incident](https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation)

Relevant bits from that section are included below for emphasis:
>  * The rationale must include an explanation for why the situation is exceptional. **Responses similar to “we deem this misissuance not to be a security risk” are not acceptable.**
> * Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a **clear timeline describing if and when the problematic certificates will be revoked or expire naturally**, and supported by the rationale to delay revocation.
> * That you will perform an analysis to determine the factors that prevented timely revocation of the certificates, and **include a set of remediation actions in the final incident report that aim to prevent future revocation delays.**

It may be helpful to review some of the [still open](https://wiki.mozilla.org/CA/Incident_Dashboard#Revocation_Delays) reports from some CAs, as well as some of the [past incidents](https://wiki.mozilla.org/CA/Closed_Incidents#Delayed_Revocation)

Back to Bug 1619179 Comment 4