On Sat, Jul 4, 2020 at 12:52 PM mark.arnott1--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> This is insane! > Those 300 certificates are used to secure healthcare information systems > at a time when the global healthcare system is strained by a global > pandemic. I have to coordinate with more than 30 people to make this > happen. This includes three subsidiaries and three contract partner > organizations as well as dozens of managers and systems engineers. One of > my contract partners follows the guidance of an HL7 specification that > requires them to do certificate pinning. When we replace these > certificates we must give them 30 days lead time to make the change. > As part of this, you should re-evaluate certificate pinning. As one of the authors of that specification, and indeed, my co-authors on the specification agree, certificate pinning does more harm than good, for precisely this reason. Ultimately, the CA is responsible for following the rules, as covered in https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation . If they're not going to revoke, such as for the situation you describe, they're required to treat this as an incident and establish a remediation plan to ensure it does not happen again. In this case, a remediation plan certainly involves no longer certificate pinning (it is not safe to do), and also involves implementing controls so that it doesn't require 30 people, across three subsidiaries, to replace "only" 300 certificates. The Baseline Requirements require those certificates to be revoked in as short as 24 hours, and so you need to design your systems robustly to meet that. There are proposals to the Baseline Requirements which would ensure this is part of the legal agreement you make with the CA, to make sure you understand these risks and expectations. It's already implicitly part of the agreement you made, and you're expected to understand the legal agreements you enter into. It's unfortunate that this is the first time you're hearing about them, because the CA is responsible for making sure their Subscribers know about this. > After wading through this very long chain of messages I see little > discussion of the impact this will have on end users. Ryan Sleevi, in the > name of Google, is purporting to speak for the end users, but it is obvious > that Ryan does not understand the implication of applying these rules. > I realize you're new here, and so I encourage you to read https://wiki.mozilla.org/CA/Policy_Participants for context about the nature of participation. I'm very familiar with the implications of applying these rules, both personally and professionally. This is why policies such as https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation exist. This is where such information is shared, gathered, and considered, as provided by the CA. It is up to the CA to demonstrate the balance of equities, but also to ensure that going forward, they actually adhere to the rules they agreed to as a condition of trust. Simply throwing out agreements and contractual obligations when it's inconvenient, *especially *when these were scenarios contemplated when they were written and CAs acknowledged they would take steps to ensure they're followed, isn't a fair, equitable, or secure system. This is the unfortunate nature of PKI: as a system, the cost of revocation is often not properly accounted for when CAs or Subscribers are designing their systems, and so folks engage in behaviours that increase risk, such as lacking automation or certificate pinning. For lack of a better analogy, it's like a contract that was agreed, a service rendered, and then refusing to pay the invoice because it turns out, it's actually more than you can pay. We wouldn't accept that within businesses, so why should we accept here? CAs warrant to the community that they understand the risks and have designed their systems, as they feel appropriate, to account for that. That some have failed to do is unfortunate, but that highlights poor design by the CA, not the one sending the metaphorical invoice for what was agreed to. Just like with invoices that someone can't pay, sometimes it makes sense to work on payment plans, collaboratively. But now that means the person who was expecting the money similarly may be short, and that can quickly cascade into deep instability, so has to be done with caution. That's what https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation is about However, if someone is regularly negligent in paying their bills, and have to continue to work on payment agreements, eventually, you'll stop doing business with them, because you realize that they are a risk. That's the same as when we talk about distrust. Peter Bowen says > > ... simply revoking doesn't solve the issue; arguably it makes it > > worse than doing nothing. > > You are absolutely right, Peter. Doctors will not be able to communicate > with each other effectively and people could die if the CA/B forum > continues to blindly follow its rules without consideration for the greater > impact this will have on the security of the internet. To be clear; "the issue" we're talking about is only truly 'solved' by the rotation and key destruction. Anything else, besides that, is just a risk calculation, and the CA is responsible for balancing that. Peter's highlighting how the fix for the *compliance* issued doesn't fix the *security* issue, as other CAs, like DigiCert, have also noted. The process, as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation , understands these tradeoffs and acknowledges that CAs, by and large, have been derelict in their duties to balance them. It's easy to blame folks holding CAs accountable to their commitments and contractual obligations, but that doesn't make a better system. CAs that are faced in these difficult positions are supposed to come up with plans to correct it, but the system has to be moving to a place where this no longer happens. This can be by the eventual distrusting of a CA that continues to have incidents and fails to design for them, or by the distrusting of a CA that continues to disregard their commitments. It's possible for a single incident to be so severe it leads to distrust, but in general, these incidents are viewed as collaborations where the CA comes up with a plan to systematically identify the issue and fix it. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
