On 28/12/2018 19:44, Lee wrote: > On 12/27/18, Jakob Bohm via dev-security-policy > <[email protected]> wrote: >> Looking at the BRs, specifically BR 4.9.1, the reasons that can lead >> to fast revocation fall into a few categories / groups: > <.. snip ..> >> 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. > > My guess is all CAs have something like > https://www.digicert.com/certificate-terms/ > 15. Certificate Revocation. DigiCert may revoke a Certificate without > notice for the reasons stated in the CPS, including if DigiCert > reasonably believes that: > ... > h. the Certificate was (i) misused, (ii) used or issued contrary to > law, the CPS, or industry standards, or (iii) used, directly or > indirectly, for illegal or fraudulent purposes, such as phishing > attacks, fraud, or the distribution of malware or other illegal or > fraudulent purposes,
These were covered in the list you snipped, and shouldn't happen for an *honest* subscriber. > i. industry standards or DigiCert’s CPS require Certificate > revocation, or revocation is necessary to protect the rights, > confidential information, operations, or reputation of DigiCert or a > third party. This is a catch all clause covering emergencies and BR requirements. My list that you entirely snipped breaks down the circumstances where the BRs require revocation at short notice. > > An underscore in the name ...> Please keep the underscore issue out of this thread, which is about the general question of what kind of notice the millions of small (and large) certificate subscribers are realistically supposed to get when CAs change their mind about already issued certificates. 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
