(In reply to Jacob Hoffman-Andrews from comment #27) > We did not do so at that time. Even with the benefit of hindsight, we do not believe that would have been a reasonable response to the thread. Could you explain a bit more the thinking here? It's unclear if you're speaking specifically to this thread, or more generally with respect to incident disclosures and investigations. More generally: What are the things that would cause LE to review their CP/CPS? Given the many CP/CPS issues that have been raised for CAs recently, presumably, there are some incidents that would, and I think it's useful to better understand where/how LE defines the line. > > I think it would benefit Let's Encrypt to re-do the root cause analysis. I just want to commend LE for actually delivering on this request with the level of detail that demonstrates understanding and helps assuage the concerns. > We have a new-engineer reading syllabus that includes several incident reports. Could you share some more details about this? This seems to be within the class of helping other CAs learn from and prevent similar issues. Given Let's Encrypt's use of GitHub and transparency in activities, has there been any thought to maintaining this in a public way, e.g. in a public Git instance (such as GitHub), similar to the CP/CPS? I don't think that this decision is a blocker for this incident, but it seems that there's an opportunity here in the spirit (but not requirement) of "Therefore, the incident report should share lessons learned that could be helpful to all CAs to build better systems." (from [https://wiki.mozilla.org/CA/Responding_To_An_Incident]) > We intend to have the mdsp/bugzilla review rotation in place by 2021-06-15. We intend to complete the retrospective review by 2021-11-12. > > We intend to have our re-review of CP and CPS and updated review guidelines done by 2021-06-21. Mostly since I missed these in the first read through, just reformatting this for the next reader :) | Date | Mitigation | | -- | --- | | ~~2021-06-15~~ | ~~m.d.s.p. and Bugzilla review rotation established~~ (Complete; Comment #28) | | 2021-06-21 | Review of CP/CPS to ensure internal consistency between sections | | 2021-11-12 | Review of historic CA compliance incidents in Bugzilla for other areas of interpretation, clarification, or expectation |
Bug 1715455 Comment 29 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Jacob Hoffman-Andrews from comment #27) > We did not do so at that time. Even with the benefit of hindsight, we do not believe that would have been a reasonable response to the thread. Could you explain a bit more the thinking here? It's unclear if you're speaking specifically to this thread, or more generally with respect to incident disclosures and investigations. More generally: What are the things that would cause LE to review their CP/CPS? Given the many CP/CPS issues that have been raised for CAs recently, presumably, there are some incidents that would, and I think it's useful to better understand where/how LE defines the line. > > I think it would benefit Let's Encrypt to re-do the root cause analysis. I just want to commend LE for actually delivering on this request with the level of detail that demonstrates understanding and helps assuage the concerns. > We have a new-engineer reading syllabus that includes several incident reports. Could you share some more details about this? This seems to be within the class of helping other CAs learn from and prevent similar issues. Given Let's Encrypt's use of GitHub and transparency in activities, has there been any thought to maintaining this in a public way, e.g. in a public Git instance (such as GitHub), similar to the CP/CPS? I don't think that this decision is a blocker for this incident, but it seems that there's an opportunity here in the spirit (but not requirement) of "Therefore, the incident report should share lessons learned that could be helpful to all CAs to build better systems." (from https://wiki.mozilla.org/CA/Responding_To_An_Incident) > We intend to have the mdsp/bugzilla review rotation in place by 2021-06-15. We intend to complete the retrospective review by 2021-11-12. > > We intend to have our re-review of CP and CPS and updated review guidelines done by 2021-06-21. Mostly since I missed these in the first read through, just reformatting this for the next reader :) | Date | Mitigation | | -- | --- | | ~~2021-06-15~~ | ~~m.d.s.p. and Bugzilla review rotation established~~ (Complete; Comment #28) | | 2021-06-21 | Review of CP/CPS to ensure internal consistency between sections | | 2021-11-12 | Review of historic CA compliance incidents in Bugzilla for other areas of interpretation, clarification, or expectation |