Today we see many CAs who don’t want to go through a forced revocation event who use their Subscribers’ ostensible incompetence as an excuse for their own failed CA operations. This can only be either deliberate misdirection or extreme ignorance and misunderstanding of the responsibilities and nature of a public CA.
It’s quite simple. The CA’s responsibility is to perform the revocation within the allocated timeframe. That’s all. The Subscriber’s responsibility is to deploy replacement certificates from the misissuing CA or another, on time to avoid an outage or not. The CA’s responsibility does not extend to the Subscriber’s certificate agility or lack thereof. It does not include the Subscriber’s process or involved parties or governing law. It does not include the nature, severity, duration, or likelihood of a resulting outage. This is all the Subscriber’s responsibility. The risk/reward analysis of running an operation that cannot weather a forced revocation event is the Subscriber’s to calculate. The consequential process and resourcing decisions are the Subscriber’s to make. The public-versus-private trust analysis is something only the Subscriber can conduct. Which is appropriate, since the Subscriber has to live with the consequences. In the event of a forced revocation, if the Subscriber deploys the new, replacement certs on time, then everything continues to run. And if not, then not. This is the only conceivable model that can actually work. There is no mechanism for CAs to reliably determine if “critical infrastructure” uses their certificates and no clear definition of what qualifies as critical. There is no way for a CA to realistically evaluate the consequences of a revocation event. And unfortumately, we have a healthy dose of empirical evidence telling us that Subscribers are unreliable reporters of the nature of their own services and the severity of downtime. There is research<https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/J3aX8OKIT_A/m/xB723PIsAQAJ> suggesting that three quarters of CAs with current mandatory revocation events are not getting them done in five days, and that at 30 days in, multiple CAs still have more than 95% of their certificates unrevoked. If my memory serves me correctly, 100% of these CAs have blamed their revocation failure on Subscribers’ inability to swap out these certs and the terrible consequences of a potential outage. These CAs would have us believe that more than 95% of their certificates enable critical functionality that cannot undergo an outage without such disastrous consequences that they warrant throwing out the only error mitigation mechanism the WebPKI possesses. It defies credibility that this is true for any CA in the world, let alone three quarters of those with a misissuance event. Our own experience with forced revocation events here at Sectigo has shown us that Subscribers will always ask for more time. They will always say they can’t get it done and that the effect of not getting it done will be disaster. That makes sense. An unscheduled certificate replacement exercise is inconvenient for the Subscriber. It takes time that could be spent on other tasks. It adds hassle and worry. It may cost overtime or incremental service budget. Of course the Subscribers don’t want to do it, so when they are allowed to choose, they choose not to. But when the CA simply offers that this revocation will occur in a specified timeframe, the Subscribers miraculously get the new certificates deployed. Every time. We see this miracle occur over and over again. It could be that Sectigo has the luckiest and most competent set of Subscribers on the planet. Or maybe, just maybe, the fact is that nearly all Subscribers can handle a forced revocation event when it occurs. They simply don’t want to. If CAs had sufficient emotional fortitude and commitment to the principles they had signed up for, they would complete all these revocations on time, and the Subscribers would manage to deploy their new certificates, and we wouldn’t be having this conversation. But the evidence overwhelmingly tells us that CAs do not. So what we need is for this decision to stay out of the CA’s hands. In fact, by the BRs and root program rules as written, with the exception of Mozilla, CAs do not have the authority to make this decision today. It’s just that the CAs are nonchalantly violating these rules and for the most part there have not yet been visible consequences. (Though we should note the likelihood that mismanagement of revocations was a contributing factor in the recent distrust of ecommerce monitoring GMBH.) It is within the power of major root programs to affect policies and/or software functionality that will change CAs’ risk/reward decisions. This can be threat of distrust but also could include less severe consequences. Community participants have suggested ideas including capping the maximum term for offending CAs at 90 days, distrusting the EV roots of offending CAs, and enforcing a browser-side ban on misissued certificates after the revocation deadline. These are all technically possible, and each root program will evaluate if one of these ideas, or another, makes sense. I personally believe that any of these outcomes would have been motivational for most or all of the current offending CAs to complete their revocations on time. I further believe that, in the absence of a completed revocation, they would have meaningful mitigating effects on these and future incidents from the same CAs. -tlc From: [email protected] <[email protected]> On Behalf Of Mike Shaver Sent: Friday, May 24, 2024 5:41 PM To: Aaron Gable <[email protected]> Cc: [email protected] Subject: Re: issuance to subscribers who cannot tolerate prompt revocation CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Fri, May 24, 2024 at 5:22 PM Aaron Gable <[email protected]<mailto:[email protected]>> wrote: On the whole, I certainly agree with your sentiment here: Subscribers who cannot replace a certificate in less than 5 days are not protecting the privacy and the security of their users, and either need to improve their response time or investigate non-WebPKI solutions. And CAs which knowingly issue to such Subscribers (perhaps because that Subscriber has failed to replace a certificate in a prior incident) are asking for trouble. The problem is this: the “trouble” is being pushed onto the users of WebPKI, because the Subscriber’s unwillingness to accept prompt revocation is used along with what I think is bad faith abuse of the latitude provided to CAs to unilaterally delay revocation and therefore keep misissued certificates in use for an extended period of time (more than a month in some cases!). This represents real risk for the web, not only because in the event of a key compromise, if the pronouncements of the CAs in question are true, we would have to choose between an insecure web and harm to human health or critical infrastructure. Having misissued certificates (of any kind) in circulation harms the ability of WebPKI users to rely on the BRs’ guarantees, and risks interoperability issues for new entrants. Section 1.4.2 of the CPS does not have any requirement that WebPKI certificates not be used in critical contexts, but if we are told that it is disastrous to revoke these certificates in a timely manner, then perhaps there should be some minimum exclusions. (Perhaps there is a CA who genuinely believes that their certificates are reliable enough for such uses, though? A scan of some CPSes sort of indicates that, but I expect it is more omission than deliberate choice.) But I also think that issuing to such a Subscriber is not necessarily itself a misissuance. The Subscriber has agreed to a legally binding Subscriber Agreement which includes the necessary warranties. It is not necessarily the CA's fault -- though it is their problem -- that the Subscriber has failed to understand the full ramifications of that warranty. I honestly don’t care about whose fault it is, just how to avoid this pattern repeating. Some of these Subscribers have been using a given CA’s certs for longer than the BRs have existed, and—barring force majeure use of something like OneCRL—the CAs are the only ones who can keep the risk and harm from being externalized to the users who rely on the WebPKI. CAs are knowingly entering into these arrangements, and if you’re correct that it’s not a misissuance then I don’t understand what point 8 being in the baseline requirements is. Relatedly, what is the purpose of requiring the acknowledgements of that section to be legally binding, if the CAs don’t have a responsibility to use that legal tool and revoke misused certificates? Any CA could themselves add such a clause to their terms if they wanted it themselves, but unfortunately I do not recall the motivation for making such a requirement part of the BRs. Maybe it’s in mailing list archives? Mike -- You received this message because you are subscribed to the Google Groups "CCADB Public" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZqtoOnz5TXr9vh1tKrka%3DU3SC0vMLPoUhR7ySV4uqZViuw%40mail.gmail.com<https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZqtoOnz5TXr9vh1tKrka%3DU3SC0vMLPoUhR7ySV4uqZViuw%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "CCADB Public" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/SJ0PR17MB5935D6187D5C69E8B6AC1A3086F32%40SJ0PR17MB5935.namprd17.prod.outlook.com.
