On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy < [email protected]> wrote:
> 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? > > Yes, it was: * QuoVadis * AC Camerfirma, S.A. * Chunghwa Telecom Corporation * Start Commercial (StartCom) Ltd. QuoVadis disclosed their intermediate within a few hours of my email, the others still have not. > > > 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 > Alex _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
