Isn't the evident answer, if reasonable compromise is not forthcoming, just to publish the compromised private key. There's no proof of a compromised private key quite as good as providing a copy of it.
I understand the downsides, but I think that capricious burdens encourage stripping the issue bare. You can't dodge a copy of a key. On Tue, Mar 10, 2020 at 5:31 PM Piotr Kucharski via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
