Looking at the BRs, specifically BR 4.9.1, the reasons that can lead to fast revocation fall into a few categories / groups:
(I will reference the numbered items with 24 hour limit as A#, the numbered items with 120 hour limit as B# and the numbered items in 4.9.1.2 as C#). (Some of the numbered items A1 to C9 fall under different categories depending on concrete circumstances). G1. Explicit actions by the subscriber themselves (A1, A2, B4, B6): These are triggered and timed by their own actions and are not really unexpected or sudden. G2. Dishonest actions by the subscriber themselves (A2, B2, B3, B4, B5, B8): The subscriber brought this upon themselves, no (or little) mercy. G3. An underlying security failure in the subscriber's systems/organization (A3, B5, B11): These are easily explained by the actual security incident, and any haste and recrimination goes to that incident, the certificate revocation is a necessary action to protect the subscriber from the effects of the security failure. G4. Massive failure at the CA (B9, all of C): This is typically a major situation affecting large parts of the Internet (unless it was an unusually small CA). Global disaster mitigation is generally initiated in such rare situations. G5. The CAB/F changes the minimum key strength requirements in BR 6.1.5 or 6.1.6 without a transition period (B1, C3): This would typically be voted down by a majority of CAs. G6. The CA has second thoughts / doubts about how they validated the information in the certificate even though that information is actually correct (A4, B7): This is an operational failure at the CA, and rightly justifies blame against the CA (however it would be nice if those two BR points allowed retroactive correction similar to A2 and C2). G7. The CA made a technical error in the certificate (B7, C5): Again an operational error that justifies blaming the CA. G8. CA specific rules not required by the BRs (B10, C9): Clearly blameable on the CA, and possibly a reason to not choose that CA in the first place. So absent a bad CA, I wonder where there is a rule that subscribers should be ready to quickly replace certificates due to actions far outside their own control. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
