The idea of a grading system being used to judge CAs compliance will be a total disaster. We should instead be focusing our efforts on more transparency.
James -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jb=0.me...@lists.mozilla.org] On Behalf Of Tim Hollebeek via dev-security-policy Sent: 07 February 2018 16:11 To: Alex Gaynor <agay...@mozilla.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Paul Kehrer <paul.l.keh...@gmail.com> Subject: RE: Misissuance/non-compliance remediation timelines Alex, Most CAs probably wouldn’t aim for an A. I don’t think doing this would be a game changer. However there are some CAs that would. And I think that would be a positive thing, and lead to more innovation in best practices that could become mandatory for everyone over time. And I don’t disagree with you that action is needed on those who are currently getting Ds. I’m very disturbed by the behavior of about half of the CAs in the industry. -Tim From: Alex Gaynor [mailto:agay...@mozilla.com] Sent: Wednesday, February 7, 2018 8:15 AM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: Paul Kehrer <paul.l.keh...@gmail.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Misissuance/non-compliance remediation timelines Hey Tim, A piece I think I'm missing is what you see as the incentive for CAs to aim for an "A" rather than being happy to have a "B". It reminds me of the old joke: What do you call the Dr^W CA who graduated with a C average? Dr.^W trusted to assert www-wide identity :-) That said, given the issues Paul highlighted in his original mail (which I wholeheartedly concur with), it seems the place to focus is the folks who are getting Ds right now. Therefore I think the essential part of your email is your agreement that CAs which are persistently low performing need to be recognized and potentially penalized for the sum total of their behaviors. Alex On Tue, Feb 6, 2018 at 8:30 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > 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- > <mailto:dev-security-policy-> > bounces+tim.hollebeek=digicert....@lists.mozilla.org > bounces+<mailto:digicert....@lists.mozilla.org> ] On Behalf Of Paul > Kehrer via dev-security-policy > Sent: Tuesday, February 6, 2018 6:03 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > 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 > dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
