I only ask because telling people to go back to the CA and work something out isn’t a great answer when the retort is that the CA will be distrusted if they don’t. Either the customer doesn’t replace all their certs and they are made non-functional by revocation or the certs are distrusted because the CA isn’t operational anymore. Telling people to go have the CA cover the risk when those are the two options seems like we’re avoiding the public discussion.
From: Ryan Sleevi <[email protected]> Sent: Friday, December 7, 2018 2:26 PM To: Jeremy Rowley <[email protected]> Cc: mozilla-dev-security-policy <[email protected]> Subject: Re: CA Communication: Underscores in dNSNames On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy <[email protected] <mailto:[email protected]> > 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
