I wholeheartedly agree that revocation is a must within the required timeframes. We've had automation being used as an excuse for delayed revocation, but I don't think that's telling us the full story. There is the elephant in the room that the CA industry is a commercial operation, and automation can be seen as another revenue point. Repeated revocations in a short timeframe also impact subscriber relations and provide perverse incentives to a CA in how they handle incident response.
To that end I want CAs to consider if they, or competitors, are charging for automation and what benefits that brings to the WebPKI ecosystem. Of course, there is a difference between charging for support personnel in configuring the environment vs responding to ACME requests. I doubt this will be a public topic, but please consider it in your private discussions however. On Thursday, May 30, 2024 at 9:20:33 AM UTC+1 Tim Callan wrote: > 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]> 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]. > 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/c17f77b6-9bbf-49c3-bda1-de496b867ee9n%40ccadb.org.
