For 0% of impact the FPs do not matter that much, so agreed! Of course for now reality is not that... yet! https://github.com/certbot/certbot/issues/1028 seems so appropriate :)
PS I was definitely not advocating for 5% false negative, no; we must strive for 0% false negatives as well; all I was saying was exercising caution for the perhaps-not-so-clear-cut 5% cases. (Probably closer to 1%) On Tue, 10 Mar 2020 at 23:08, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Tue, Mar 10, 2020 at 5:56 PM Piotr Kucharski <b...@google.com> wrote: > >> I'm sympathetic to CAs wanting to filter out the noise of shoddy reports >>> and shenanigans, but I'm also highly suspicious of CAs that put too >>> unreasonable an onus on reporters. It seems, in the key compromise case, >>> the benefit of the doubt should largely deal with the reporter. If we saw >>> some quantifiable increase in hijinks and misrevocations, there are a >>> myriad of ways to deal with that. The most effective of these reasons seems >>> to be facilitating rapid replacement of certificates, rather than >>> preferring ossification. >>> >> >> I am totally against putting unreasonable onus on reporters! But >> hopefully you agree that CAs should strive for zero false positives in >> revocations. >> > > I'd happily take a 95% false positive of revocations if there were 0% > impact in the revocation (e.g. due to easy replacement). I'm mainly > hesitant to setting up a system of 0% false positives but which has a 5% > false negative. > > That's why I'm less excited for standard systems of signaling revocation > (not that there isn't some value!), and more keen on systems that make > revocation easier, quicker, and less-impactful. That's obviously Hard Work, > but that's the exciting part of working in PKI. Everything is Hard Work > these days :D > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
