Bugzilla

(In reply to Man Ho from comment #21)
> Here below a status update of the outstanding action items.
> 
> | Action Item | Kind | Due Date |
> | ----------- | ---- | -------- |
> |4. Educate customers on the certificate revocation requirement, train them on the impact analysis to their e-services and facilitate their preparation for a swift certificate replacement process, and contingency planning for enforced certificate revocation to minimize disruptions to e-services.| Prevent | 2024-06-30 |

I'm impressed that you will be done educating customers in just a few weeks. **What is the expected outcome of that education? How will you know that it was successful?**

Also, how will you educate new subscribers about the potential for short-notice revocation? I assume that your terms and conditions already inform them of this, as required by the BRs--is there additional information required for the subscribers here?

Finally, I want to reiterate that educating customers should not have any impact on Hongkong Post's ability to comply with the BR requirements for revocation. Customers can make choices that have an effect on what the operational impact is for them when a certificate is revoked, but if they do not choose to mitigate that appropriately, Hongkong Post is still responsible for revoking appropriately when they have misissued certificates.

I also want to review this earlier comment from Hongkong Post for emphasis:

(In reply to Man Ho from comment #16)
> Hongkong Post CA has been committed to following the BRs to protect the security and integrity of WebPKI.  In this incident, the remediation of the software bug by our software vendor has failed to meet the agreed service level and caused prolonged delay.

Neither the software bug nor the software vendor's timeline for a fix are the cause of this incident. This incident was caused **solely** by Hongkong Post's unwillingness to meet their commitments to the BRs and root programs. **If a misissuance due to software bug happens tomorrow, and the software vendor says that the fix will take two weeks, will Hongkong Post revoke within the prescribed timelines (24hr/120hr)?** That is the most important commitment to make, and it is the **only** thing that can actually prevent a repeat of this incident.

Finally, Mozilla's delayed revocation incident response expectations include the following:

> * Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.

**Can you please provide some detail as to how you worked with your auditor and any applicable root programs to ensure that your risk analysis was acceptable?**

(In reply to Man Ho from comment #21)
> Here below a status update of the outstanding action items.
> 
> | Action Item | Kind | Due Date |
> | ----------- | ---- | -------- |
> |4. Educate customers on the certificate revocation requirement, train them on the impact analysis to their e-services and facilitate their preparation for a swift certificate replacement process, and contingency planning for enforced certificate revocation to minimize disruptions to e-services.| Prevent | 2024-06-30 |

I'm impressed that you will be done educating customers in just a few weeks. **What is the expected outcome of that education? How will you know that it was successful?**

Also, how will you educate new subscribers about the potential for short-notice revocation? I assume that your terms and conditions already inform them of this, as required by the BRs--is there additional information required for the subscribers here?

Finally, I want to reiterate that educating customers should not have any impact on Hongkong Post's ability to comply with the BR requirements for revocation. Customers can make choices that have an effect on what the operational impact is for them when a certificate is revoked, but if they do not choose to mitigate that appropriately, Hongkong Post is still responsible for revoking appropriately when they have misissued certificates.

I also want to review this earlier comment from Hongkong Post for emphasis:

(In reply to Man Ho from comment #16)
> Hongkong Post CA has been committed to following the BRs to protect the security and integrity of WebPKI.  In this incident, the remediation of the software bug by our software vendor has failed to meet the agreed service level and caused prolonged delay.

Neither the software bug nor the software vendor's timeline for a fix are the cause of this incident. This incident was caused **solely** by Hongkong Post's unwillingness to meet their commitments to the BRs and root programs. **If a misissuance due to software bug happens tomorrow, and the software vendor says that the fix will take two weeks, will Hongkong Post revoke within the prescribed timelines (24hr/120hr)?** That is the most important commitment to make, and it is the **only** thing that can actually prevent a repeat of this incident.

Finally, Mozilla's delayed revocation incident response expectations include the following:

> *  The decision and rationale for delaying revocation will be disclosed in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include detailed and substantiated explanations for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.
> * Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.

**This incident does not have a per-Subscriber description of the rationale, which should include details about the unacceptable effects that would occur if the certificates were revoked on time.  When will Hongkong Post provide this information?**

**Can you please provide some detail as to how you worked with your auditor and any applicable root programs to ensure that your risk analysis was acceptable?**

(In reply to Man Ho from comment #21)
> Here below a status update of the outstanding action items.
> 
> | Action Item | Kind | Due Date |
> | ----------- | ---- | -------- |
> |4. Educate customers on the certificate revocation requirement, train them on the impact analysis to their e-services and facilitate their preparation for a swift certificate replacement process, and contingency planning for enforced certificate revocation to minimize disruptions to e-services.| Prevent | 2024-06-30 |

I'm impressed that you will be done educating customers in just a few weeks. **What is the expected outcome of that education? How will you know that it was successful?**

Also, how will you educate new subscribers about the potential for short-notice revocation? I assume that your terms and conditions already inform them of this, as required by the BRs--is there additional information required for the subscribers here?

Finally, I want to reiterate that educating customers should not have any impact on Hongkong Post's ability to comply with the BR requirements for revocation. Customers can make choices that have an effect on what the operational impact is for them when a certificate is revoked, but if they do not choose to mitigate that appropriately, Hongkong Post is still responsible for revoking appropriately when they have misissued certificates.

I also want to review this earlier comment from Hongkong Post for emphasis:

(In reply to Man Ho from comment #16)
> Hongkong Post CA has been committed to following the BRs to protect the security and integrity of WebPKI.  In this incident, the remediation of the software bug by our software vendor has failed to meet the agreed service level and caused prolonged delay.

Neither the software bug nor the software vendor's timeline for a fix are the cause of this incident. This incident was caused **solely** by Hongkong Post's unwillingness to meet their commitments to the BRs and root programs. **If a misissuance due to software bug happens tomorrow, and the software vendor says that the fix will take two weeks, will Hongkong Post revoke within the prescribed timelines (24hr/120hr)?** That is the most important commitment to make, and it is the **only** thing that can actually prevent a repeat of this incident.

Finally, Mozilla's delayed revocation incident response expectations include the following:

> *  The decision and rationale for delaying revocation will be disclosed in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include detailed and substantiated explanations for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.
> * Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.

**In my opinion, this incident's list of affected certificates does not have a sufficiently-detailed per-Subscriber description of the rationale, which should include details about the unacceptable effects that would occur if the certificates were revoked on time.  Will Hongkong Post provide this information?**

And: **Can you please provide some detail as to how you worked with your auditor and any applicable root programs to ensure that your risk analysis was acceptable?**

[Edited to clarify per-subscriber detail request.]