A bit over 5 months ago I reported a series of OCSP responders that were violating BRs (section 4.9.10) by returning GOOD on unknown serial numbers. Since that time the majority of those responder endpoints have been fixed, but several are still non-compliant; either with little communication or continuing assurances that it will be fixed "soon", where soon is a date that continuously slides into the future.
At the moment Mozilla possesses very few options when it comes to punitive action and the lesson some CAs appear to be learning is that as long as you don't rise to PROCERT levels of malfeasance/incompetence then the maximum penalty is censure on bugzilla and email threads. Clearly this is not a deterrent. So, how long is too long? At what point should a CA incur consequences (and what form can those consequences take) for failure to remediate despite being given such immense latitude? As a straw man: what if we developed a set of technical constraints related to minimizing risk associated with CAs that are deemed to be acting poorly? For example, CAs deemed a risk would have their certificate maximum lifetime constrained to some amount less than the BRs currently allow. Additional penalties could include removal of EV trust indicators, constraining trust to a limited set of domains, marking contexts as insecure, and finally full distrust. Once a CA lands in a risk category further misissuance would escalate their risk to the community and thus incur additional constraints. (I'm sure the community can come up with far better tiers than I have!) Adding controls like this will require significant time and effort from Mozilla, but if we want to be able to manage the significant and ongoing volume of misissuance/non-compliance we're seeing I believe some level of granularity is needed. -Paul (reaperhulk) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
