On Fri, Mar 15, 2019 at 8:54 AM Andrew via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Perhaps the solution should be to amend the BRs to allow for more flexible > handling of situations such as this. > > After a long debate, the BR revocation requirements were recently relaxed a bit. It's not realistic or desirable to again change these requirements simply as a reaction to the current situation, no matter how silly it seems. I understand that'd be rather difficult to formalize, since we can't just > trust the CAs to decide for themselves when mass revocation doesn't make > sense (as they have a vested interest in not revoking), and security impact > isn't something that's easy to objectively quantify. However, the current > status quo where millions of certs need to be revoked due to a technicality > that has practically no impact on actual security seems silly. > > Anything short of entirely removing the BR revocation requirement would be impossible to formalize. So we either have a situation in which the BRs default to assuming that misissuance creates risk, or the BRs default to a position in which they don't provide any normative guidance. The serial number problem is a rather extreme example in which misissuance is not introducing much risk to the web PKI, but we can't predict where future forms of policy violations will fall in terms of risk. Remember that the security impact of revoking still-in-use certificates > that do not actually pose a security risk is negative, as it leads to > warning fatigue. Users who frequently encounter warnings about revoked > certificates are more likely to bypass those warnings in the future. Not to > mention the negative impact on the CA system as a whole, with increased > operating costs for CAs and customers alike resulting from the additional > work required to replace certificates. > > I understand that this is a hard problem, but ultimately we need to be able to replace certificates quickly and easily so that revoking them doesn't create an availability risk. Heartbleed and SHA-1 are just two events that provide evidence that we need to be prepared for a serious, widespread incident that requires mass certificate replacement. On Friday, March 15, 2019 at 12:11:40 AM UTC-5, Ryan Sleevi wrote: > > On Fri, Mar 15, 2019 at 12:36 AM Jaime Hablutzel via dev-security-policy > < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > Could you please provide me a link to a previous discussion where the > > > negative was stated, maybe by the module owner?. But note that I'm not > > > asking for a bespoke or improvised exception for the current issue but > for > > > the possibility to introduce a procedure to handle any type of low > > > breach/high disruption violations now and in the future?. > > > > > > > "However, Mozilla does not grant exceptions to the BR revocation > > requirements." [1] > > "In my opinion, Mozilla should not get in to the business of granting > > one-off exceptions ..." [2] > > > > [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident > > [2] > > > https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/HNDX5LaZCAAJ > > (That's this thread, one week ago) > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
