Hi MDSP community,
There have been a number of past issues where actual practices followed by CAs deviated from published practices. We recently had a delay in publishing our CPS which resulted in our CPS not removing language that accommodated a practice we were no longer using as a result of code changes we had deployed to prevent the practice. After reviewing past incidents, current requirements, and considering improvements we could make, it led us to question whether there is an opportunity to improve the timeliness and accountability for CPS publications across the ecosystem to accurately reflect actual practices. There are a number of common reasons that a CPS might drift, for example: - Canary deployments (https://martinfowler.com/bliki/CanaryRelease.html), where a change is rolled out to a small subset of users as an initial test before making it available to everybody. - Rapid deployment of a change containing a needed security fix or security enhancement. - Enhancing a process to be more restrictive than the CPS. - CPS updates may be necessary before a new type of certificate is issued to get the trust store approval, for example to get permission to issue code signing certificates. - Delays in obtaining reviews from external stakeholders such as the policy authority, executives, or legal team. There are also a number of anti-patterns that might contribute to unnecessary delays in updates, for example: - Update processes where changes to the CPS are only made following a fixed schedule. - Bundling of many updates together into a large update, slowing review and publication. - Changes in practices not being reflected in the CPS due to process gaps. - Challenges prioritizing CPS reviews and edits against other high-priority items such as those in an action plan relating to an incident. As we look at these cases it seems there may be cases where drifts in code behavior and the CPS, while not ideal, may be unavoidable, which is made more complicated for the community since such drifts are difficult for the community to detect. This leads us to think that there may be value in having a clear lower bound in which drift is acceptable added to the BRs where auditors would be expected to assess if that requirement was being met as part of the audits. Additionally we thought it would be good to have a conversation to gather the community’s thoughts around under what circumstances this does happen in your environments and what you do to manage that drift. Any thoughts would be greatly appreciated. Ryan Hurst Google Trust Services -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/37923cfa-414b-4e8f-971c-a76a4898c03cn%40mozilla.org.
