Just chiming in as another subscriber and relying party, with a view to speaking to the other subscribers on this topic.
To the extent that your use case is not specifically the WebPKI as pertains to modern browsers, it was clear to me quite several years ago and gets clearer every day: the WebPKI is not for you, us, or anyone outside that very particular scope. Want to pin server cert public keys in an app? Have a separate TLS endpoint for that with an industry or org specific private PKI behind it. Make website endpoints that need to face broad swathes of public users’ web browsers participate in the WebPKI. Get client certs and API endpoints out of it. That was the takeaway I had quite some years ago and I’ve been saved much grief for having moved that way. On Saturday, July 4, 2020, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
