On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> This isn't a CA-issue because the risk associated with non-compliance isn't > defined yet. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ ""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) or remove a certificate at any time and for any reason. This may happen immediately or on a planned future date. Mozilla will disable or remove a certificate if the CA demonstrates ongoing or egregious practices that do not maintain the expected level of service or that do not comply with the requirements of this policy."" Sounds like the risk is well-defined and documented. > From what I've heard here, the risk is distrust or loss of EV > indicators, which is distrust-like. That's a pretty big thing to push back > on the CA for a non-security issue. Thus, I think the risk of missing the > underscore revocation date needs to be discussed here so everyone, > including > website operators and the relying parties, know first-hand what the risks > of > the CA missing the deadline are. Any and every qualification or failure to abide by the program requirements comes with it the risk of sanction, up to, and including, distrust. It sounds like you're looking for a way for CAs to make a cost/benefit analysis as to whether it's more beneficial to them to violate requirements, by having a clearer guarantee what it will cost them if they intentionally do so, versus what they may gain from their Subscribers. That doesn't really seem aligned with the incentives of the ecosystem or the relying parties, since CAs (and their Subscribers) are not able to, on purely technical level, evaluate the cost or impact to Relying Parties, since Relying Parties include every possible entity that trusts that root. > If the risk is that there is a note on the > audit, that is an acceptable risk. If the risk is a loss of the > root...probably less so. Pushing the question back to the CA without > better > discussion by the browsers makes finding a solution or understanding the > risks impossible. While I think it's positive and encouraging to see CAs acknowledge that their audits exist to disclose non-conformities/qualifications, I don't think it should be seen as legitimizing or accepting that intentional non-conformities/qualifications are desirable. A well-run CA should strive to have zero qualifications, findings, or non-conformities - not because they were able to convince their auditor that they weren't issues / were minor, but because they operated above and beyond reproach, and there were literally no issues. Anything short of that is an indicator that a CA is failing in its role as a trusted steward, and repeated failures seem reasonable to discuss sanction or distrust. CAs (and their sub-CAs) with a pattern of incidents on the incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk of sanction, given the pre-existing patterns of non-compliance. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
