On Sat, Jul 4, 2020 at 5:32 PM Mark Arnott via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Why aren't we hearing more from the 14 CAs that this affects. Correct me > if I am wrong, but the CA/B form has something like 23 members?? An issue > that affects 14 CAs indicates a problem with the way the forum collaborates > (or should I say 'fails to work together') Maybe this incident should have > followed a responsible disclosure process and not been fully disclosed > right before holidays in several nations. This was something disclosed 6 months ago and 6 years ago. This is not something “new”. The disclosure here is precisely because CAs failed, when engaged privately, to understand both the compliance failure and the security risk. Unfortunately, debates about “responsible” disclosure have existed for as long as computer security has been an area of focus, and itself was a term that was introduced as way of having the language favor the vendor, not the reporter. We have a security risk introduced by a compliance failure, which has been publicly known for some time, and which some CAs have dismissed as not an issue. Transparency is an essential part of bringing attention and understanding. This is, in effect, a “20-year day”. It’s not some new surprise. Even if disclosed privately, the CAs would still be under the same 7 day timeline. The mere act of disclosure triggers this obligation, whether private or public. That’s what the BRs obligate CAs to do. > Thank you for explaining that. We need to hear the official position from > Google. Ryan Hurst are you out there? Just to be clear: Ryan Hurst does not represent Google/Chrome’s decisions on certificates. He represents the CA, which is accountable to Google/Chrome just as it is to Mozilla/Firefox or Apple/Safari. In the past, and when speaking on behalf of Google/Chrome, it’s been repeatedly emphasized: Google/Chrome does not grant exceptions to the Baseline Requirements. In no uncertain terms, Google/Chrome does not give CAs blank checks to ignore violations of the Baseline Requirements. Ben’s message, while seeming somewhat self-contradictory in messaging, similarly reflects Mozilla’s long-standing position that it does not grant exceptions to the BRs. They treat violations as incidents, as Ben’s message emphasized, including the failure to revoke, and as Peter highlighted, both Google and Mozilla work through a public post-mortem process that seeks to understand the facts and nature of the CA’s violations and how the underlying systemic issues are being addressed. If a CA demonstrates poor judgement in handling these incidents, they may be distrusted, as some have in the past. However, CAs that demonstrate good judgement and demonstrate clear plans for improvement are given the opportunity to do so. Unfortunately, because some CAs think that the exact same plan should work for everyone, it’s necessary to repeatedly make it clear that there are no exceptions, and that each situation is case-by-case. This is not a Google/Mozilla issue either: as Mozilla reminds CAs at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation , delayed revocation issues affect everyone, and CAs need to directly communicate with all of the root programs that they have made representations to. WISeKey knows how to do this, but they also know what the expectation and response will be, which is aligned with the above. Some CAs have had a string of failures, and around matters like this, and thus know that they’re at risk of being seen as CAs that don’t take security seriously, which may lead to distrust. Other CAs recognize that security, while painful, is also a competitive advantage, and so look to be leaders in an industry of followers and do the right thing, especially when this leadership can help ensure greater flexibility if/when they do have an incident. Other CAs may be in uniquely difficult positions where they see greater harm resulting, due to specific decisions made in the past that were not properly thought through: but the burden falls to them to demonstrate that uniqueness, that burden, and both what steps the CA is taking to mitigate that risk **and the cost to the ecosystem** and what steps they’re taking to prevent that going forward. Each CA is different here, which is why blanket statements aren’t a one-size fits all solution. I’m fully aware there are some CAs who are simply not prepared to rotate intermediates within a week, despite them promising they were capable of doing so. Those CAs need to have a plan to establish that capability, they need to truly make sure this is exceptional and not just a continuance of a pattern of problematic behavior, and they need to be transparent about all of this. That’s consistent with all of my messages to date, and consistent with Ben’s message regarding Mozilla’s expectations. They are different ways of saying the same thing: you can’t sweep this under the rug, you need to have a plan, and you need to understand the risks. To use the payment analogy: No one is going to say “If you can’t pay, don’t worry about it”, especially not when that will be used as precedent for future actions. Like, I might entirely be inclined to say that if we were sharing lunch and you forgot your wallet, but that doesn’t mean you can then not pay back the $100,000 you were invoices for simply because I covered your lunch. Yet that’s exactly the perspective we see from some CAs, and that’s why I emphasize the incident so strongly. Nor is a business going to tell everyone that has outstanding invoices going to say “Everyone can go on a payment plan on the exact same per-month terms until they can pay back the full amount”; for some, their outstanding debt is already substantial, and for others, the terms are going to vary based on how much is owed. These are blanket one-size-fits-all statements don’t happen. However, as spelled out in https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation , if a CA is going to ask to go on a payment plan, they have obligations to meet and need to carefully think about the terms they’re proposing. Paying back $10 over 20 years is not reasonable, just like paying back $100,000 may not be: it’s situational, depends on the facts, and that’s what these incident bugs are meant to gather and track. > For the future, HL7 probably would be well served by working to create > > a separate PKI that meets their needs. This would enable a different > > risk calculation to be used - one that is specific to the HL7 health > > data interoperability world. I don't know if you or your organization > > has influence in HL7, but it is something worth pushing if you can. > > This has been discussed in the past and abandoned, but this incident will > probably restart that discussion. This is encouraging. This is exactly the sort of things we look for from CAs when responding, as per https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation - how are they transitioning participants who pose risk off, and how are they mitigating that risk while they do so. Some CAs have addressed this via contracts: making it unambiguous and clear they will revoke as needed, so Subscribers know ip front. Some have addressed this through certificate profiles: e.g. forcing certificates to be shorter lived so as to reduce the pain of these rotations by encouraging or even necessitating automation. And many CAs have, in the past, worked to establish alternative transition plans for their Subscribers that move on to alternative PKIs that can provide the stability and certainty they need. These are all good things, and they’re all things we look for from CAs as part of understanding https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
