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> 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-
> > bounces+tim.hollebeek=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
> > 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
> > https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> 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
https://lists.mozilla.org/listinfo/dev-security-policy
