I certainly hate to just reply with a +1, but FWIW, I agree that the language "suspected or known to have suffered Key Compromise" should be interpreted to include weak keys, whether due to a known flaw or some yet-discovered issue.
I'd certainly support widening that language to help responding to events like this, Heartbleed, or whatever comes next. J.C. On Fri, Jul 14, 2017 at 12:04 PM, Ryan Sleevi via dev-security-policy < [email protected]> wrote: > On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy < > [email protected]> wrote: > > > > That's my point. The current situation is distinct from weak keys, and > > we shouldn't sacrifice the weak keys BR to make room for a compromised > > keys BR. > > > But a weak key is always suspected of having suffered a Key Compromise - is > it not? > > That is, changing to from "weak keys" to "suspected or known to have > suffered Key Compromise" in 6.1.1.3 would fully include weak keys (which > are already in scope) as well as include those excluded (compromised, > strong). This applies in addition to the requirements already present in > 6.1.5/6.1.6 regarding key sizes and strengths (which already counter your > hypothetical), and 4.9.1.1/4.9.1.2 address the situation if a strong key, > post issuance, becomes either weak or compromised. > _______________________________________________ > 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
