How is this different from the negative penalties Paul mentioned? Do you see the competition based on being the 'least bad' (i.e. more likely to get an A because of no issues than a B because of some?)
The "CA Thunderdome" advocate in me wants to know whether you envision this being graded on a curve ;) I do want to highlight something else, which is that in today's CA ecosystem model, the 'cost' of misissuance, malfeasance, or incompetence is a fully externalized cost (to relying parties, site operators, and root store administrators) unless/until that cost is recovered by distrusting or sanctioning the CA (under the assumption that there's an economic value to trust and that the loss of that trust is thus a loss of value). Perhaps its time to operate on a more explicit model, in which all CAs are assumed to have a base cost to the ecosystem that is recovered annually, with there being further cost recovery in the presence of misissuance, and reduction in cost if the CAs can demonstrate they've reduced the base ecosystem cost (for example, shorter lived certs or automation). That seems to more explicitly formalize some of the assumptions. On Tue, Feb 6, 2018 at 8:30 PM, Tim Hollebeek via dev-security-policy < [email protected]> wrote: > Paul, > > I understand your frustration. I've read some of the recent threads about > "how long does it take to update a CPS?" and clearly there needs to be > some stronger compliance language in either the BRs or Mozilla policy > ("CAs MUST be able to update their CPS within 90 days"). And as you note > such policies need to have teeth otherwise there will be some who will > just ignore them. > > However negative penalties are not the only thing that should be > considered. > Mozilla should also have some way of recognizing CAs that are performing > above and beyond the minimum requirements. I would love to see Mozilla > encourage CAs to compete to be the best CA in Mozilla's program. > > To satisfy both goals, I'd like to suggest an idea I've had for a while: at > some > point in time (annually?), Mozilla should assess their opinion of how well > each CA in the program is performing, and give them a letter grade. This > could include policy improvements like "Two consecutive failing grades, > or three consecutive C or lower grades and you're out of the Mozilla > program." > > This would not preclude other actions as Mozilla deems necessary. But it > would provide a regular checkpoint for CAs to understand either "Hey, > you're great, keep up the good work!" or "Meh, we think you're ok." or > "Your performance to date is unacceptable. Get your sh*t together or > you're gone." > > -Tim > > > -----Original Message----- > > From: dev-security-policy [mailto:dev-security-policy- > > [email protected]] On Behalf Of Paul > > Kehrer via dev-security-policy > > Sent: Tuesday, February 6, 2018 6:03 PM > > To: [email protected] > > Subject: Misissuance/non-compliance remediation timelines > > > > 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 > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
