On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy < [email protected]> wrote:
> On 05/06/17 14:29, Alex Gaynor wrote: > > As I've expressed before, I find it baffling that this still happens. > > I am also disappointed. I have half a mind to keep track of how often > this happens per CA, and impose a mandatory delay of 1 month per > incident to that CA's next attempt to include a new root or get a trust > bit or EV change in our store. :-) > A potential downside to that is that it favors incumbents, who often can continue to utilize existing root certificates, while new entrants would face a barrier to entry. That said, it absolutely should be getting tracked, per CA, as incident reports in Bugzilla and provided to the community. Alex, do you have the specific list of CAs at the time of your posting? > Aside from taking a note of how often this happens and it perhaps > appearing in a future CA investigation as part of evidence of > incompetence, does anyone else have ideas about how we can further > incentivise CA compliance with a requirement which was promulgated some > time ago, for which all the deadlines have passed, and which should be a > simple matter of paperwork? > Short of disabling trust bits on a 'go forward' basis (e.g. no new issuance after date X), most of the ideas favor existing legacy CAs at the expense of newer CAs. This is why I suggested the broader proposal of only adding root CAs with a defined 'shutdown' period (e.g. after 3-5 years), and requiring the frequent rotation of included root certificates. This ensures that the ability to distrust certificates on a go-forward basis is built into the ecosystem as the steady state, such that non-compliance, stalling tactics, incomplete disclosures, incomplete remediations, lack of addressing community questions and feedback, etc can all be appropriately addressed as the default state, with the only CAs continuing participation being those that are active and engaged with the community and the issues. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
