Point 7.1.2.8 states that "the CA Will revoke the Certificate for any of the reasons specified in these Requirements". This is a warranty made by the CA towards all "Certificate Beneficiaries", which includes "All Relying Parties who reasonably rely on a Valid Certificate", i.e. the general public.
Unfortunately, it is not made absolutely clear what "reasons specified in these Requirements" means. There are a couple of occurrences of "the CA SHALL revoke if X", but these are obviously not binding.
However, nowhere does it say that failure to pay on the side of the certificate recipient would be a reason for the CA not to do their job. I would also find it very weird if the quality of warranties made by a CA towards me depended on someone else paying the CA some money – in other words, I’m fine with the CA charging its customers to revoke certs, I’m not fine with the CA not revoking if its customers fail to pay.
But if you look at the bylaws of the CA/B forum [1], they explicitly exclude discussion of "pricing policies, pricing formulas, prices or other terms of sale" as part of their mandate.
So we can't assume a position for or against revocation charges - it's just not within the scope of the guidelines. Which are non-binding and advisory anyway.
I’m not against revocation charges per se, I’m against charges being paid prior to revocation. So a CA including something like “if we have revoke this cert, you have to pay 20$, we will revoke under these circumstances: …” would be perfectly fine with me – terms in legal contracts requiring one party to pay a certain amount if certain situations arise are not uncommon, so I don’t think this would have legal issues.
My problem is really that a CA says “we know this cert is bad but won’t revoke it, sorry about that”, just because the owner of the cert (someone absolutely irrelevant to me) doesn’t pay up.
Could you outline a scenario where you make a request that someone else's certificate be revoked, yet it's of such little importance that you refuse to pay the $25 fee that may possibly be charged?
SHALL here is an RFC2119 term which is unconditionally binding, like REQUIRED or MUST: "the definition is an absolute requirement of the specification". Zero wiggle room.
The CA's policies on whether they charge for things in general (such as reissuing) falls out of scope of CA/B Forum - but some things are absolutely required if browsers are to trust a CA, like, say, § 13.1.5: "The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:" … "3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (also see Section 10.2.4 ['… If the CA or any of its designated RAs become aware that a Subscriber’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.'])…".
After Heartbleed however, when presented with a huge list of compromised certificates, StartSSL flatly refused the emergency action the other CAs took. "No, iI's [sic] upon the subscriber to take appropriate action, the certificate authority can't control or enforce which software to use". (What's actually required from the subscriber is "[a]n obligation and warranty […] to take all reasonable measures to maintain sole control of, keep confidential, and properly protect at all times the Private Key…" [emphasis mine]. Demanding subscribers' software or hardware to be totally bug-free would be great - but is clearly unreasonable today, especially in the wake of a major internet security event.) They confirmed they wanted to make money from it. "We don't get rich from this, but we can't lose either. It's part of the deal in favor of certificates for free." (Let's Encrypt will prove them wrong here.) So, it was clarified, they'll only revoke certificates if they're paid to? "The alternative would be to charge for every certificate, what do you prefer?" Any other way, at all? "No, there isn't." People asked if they were really serious. "Dead serious."
So if a CA refused to revoke their signatures on tens of thousands of keys they've been informed are compromised as part of a major internet security event, should we all continue to trust their word that any given key is truly authentic?
Fortunately, other CAs exist. But unfortunately, thanks to PKIX's design, any bad apple spoils the whole bunch unless there's some kind of external pinning to CA/endpoint public keys too (like HPKP and/or DANE). Revocation is enough of a problem child as-is, as agl already identified, without even CAs refusing to use it. Maybe going forward, things like ACME may let us more towards shorter-term endpoint keys instead? Who knows.
> After Heartbleed however, when presented with a huge list of compromised certificates
Possibly compromised. That's why it was the subscriber's choice, to decide in the balance of probabilities whether to revoke or not.
It's not like the Debian weak keys flaw where there was absolute proof of the private key being compromised - a database of all the possible keys (at standard lengths) were generated. In that case, StartSSL revoked the certificates automatically and free of charge.
Unfortunately, it is not made absolutely clear what "reasons specified in these Requirements" means. There are a couple of occurrences of "the CA SHALL revoke if X", but these are obviously not binding.
However, nowhere does it say that failure to pay on the side of the certificate recipient would be a reason for the CA not to do their job. I would also find it very weird if the quality of warranties made by a CA towards me depended on someone else paying the CA some money – in other words, I’m fine with the CA charging its customers to revoke certs, I’m not fine with the CA not revoking if its customers fail to pay.
EDIT: Link to PDF: https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf