On 29/12/2018 15:32, Ryan Sleevi wrote: > On Fri, Dec 28, 2018 at 11:21 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >>> 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. > > > It does not seem like a productive discussion will emerge if the ontology > is going to be honest/dishonest participants. By setting it up with loaded > terms like that, it seems more likely that the engagement you’ll get is > your own. >
The term honest is a pretty simple and obvious shorthand for a subscriber that doesn't fall under any of the rules that require revocation because that subscriber should not be allowed to hold a certificate of that general nature (category G2 on my list). > That said, it’s clear you recognize that certificate holders may, at any > point, find the need for their certificates to be replaced, and whether you > fault and blame them - or their CA - for it, it does not sound like you > dispute that. So there’s likely nothing more to be said on the topic. > In the portion of my original post that Lee snipped, I worked through each fast revocation reason listed in the BRs and explained how that particular reason would usually involve fair warning for the subscriber. For example if a domain registration is allowed to expire, the CA is required by B4 (BR 4.9.1.1, second list, item 4) to revoke quickly, but the subscriber has had at least one year of advance notice as to the date when the domain would expire. Thus this falls in my category G1. If on the other hand a court of competent jurisdiction takes away a domain name for good cause, this would constitute a dishonest subscriber (according to the court), and thus the subscriber can have no expectation to get additional warning when the CA revokes under B4 (BR 4.9.1.1, second list, item 4). Thus this falls in my category G2. The problematic situation is if a CA revokes randomly or out of pure fiat without fair warning. In terms of this list and the CAB/F the problem would be if the CA inclusion policies were written or changed to create such a situation. 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
