Is it permissible for a CA to issue a certificate to a Subscriber when they know that this Subscriber does not, in fact, acknowledge and accept item 8?
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.
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.
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 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: pub...@ccadb.org <pub...@ccadb.org>
On Behalf Of Mike Shaver
Sent: Friday, May 24, 2024 5:41 PM
To: Aaron Gable <aa...@letsencrypt.org>
Cc: pub...@ccadb.org
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.
--
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
public+un...@ccadb.org.
To view this discussion on the web visit
https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZqtoOnz5TXr9vh1tKrka%3DU3SC0vMLPoUhR7ySV4uqZViuw%40mail.gmail.com.
--
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 public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZqv-6M-t0FYr0cHkzEeo-mWzVj-Db9wmEaoTU2Esy6RrWw%40mail.gmail.com.