>which is that they weren't honest about what was free and what wasn't.

You have repeatedly stated this, and it is objectively false. The StartSSL site did not forbid archiving, and thus is available [1] going back to 2004 on the Wayback Machine. This includes both the HTML FAQ page and the policy PDFs of the time. This isn't some EULA boilerplate, actual clear policies and procedures for a CA you're interested in using for your infrastructure is something that is absolutely your responsibility to read.

When discussing Revocation (clearly titled) in the FAQ and Policy & Practice statements, even very old versions stated that a fee could be charged, and that revocation was considered a separate issue for free usage due to growth of the CRL. Later (since at least mid-2010, which is 2 years before Heartbleed was even introduced and 4 years before public disclosure) made this even more explicit, put it right in the FAQ, and put a clear price on it. From the FAQ, 2010 [2], the first sentence:

>>"72) Revocations carry a handling fee of currently US$ 24.90. [...] Extended Validation certificates are exempt from the revocation handling fee."

Please explain how they "weren't honest about what was free and what wasn't." Did you "actively look at how they presented themselves" but fail to so much as glance at the FAQ or Policies documents in doing so? None of this was remotely hidden, it was literally listed twice on the front page, both in the major navigation on the top and as one of just 10 sidebar items.

>First, both end users and CAs are required to revoke certificates that are compromised

Please back up your arguments on this. WRT to end users, under what authority at all are they "required" to do jack shit? Failing to do so in SOME industries and jurisdictions MIGHT involve negligence, but even that would depend on what other measures are taken. Please link any specific legislative or regulatory authority requirements to the contrary.

As far as CAs themselves, the authority would be the CA/B (enforced by virtue of browser/OS inclusion requirements, so the real ultimate "authority" there would be Apple/Google/Microsoft/Mozilla/OSS major distros & projects). At the time when StartCom established its initial policy, v1 of the CA/B baseline requirements [3] had not even been adopted yet (BR v1 adoption was Nov 2011, effective date was July 2012). Even then, 13.1.1 merely stated that:

>>"13.1.1 REVOCATION REQUEST: The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. The process MUST be described in the CA’s Certificate Policy or Certification Practice Statement. The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and related inquiries."

There were reporting requirements, and a 13.1.5 covers circumstances under which a CA must revoke within 24 hours. The most recent version, BR 1.4.5 (1.4.6 & 1.4.7 are in review), moves revocation to section 4.9 and includes additional details and sections (including, note, that there is no maximum latency on CRLs stipulated so a dishonest CA could make them "free" but run it off a toaster that takes 20 minutes per request).

However in none of this is it required that the CA make the process available for arbitrary usage at no cost. If a subscriber refuses to pay and the CA discovers a cert falls under one or more SHALL REVOKE parts of "Reasons for Revoking a Subscriber Certificate", then they have to revoke anyway and the cost may be unrecoverable, but they are free to treat it as a debt and go after the purchaser on their own for that money (or ban them from further use of their services). StartCom had a written laid out policy and procedure, and it was available continuously on their site. What requirement did they fail at?

>Second, CAs provide revocation services like OCSP for revoked and non-revoked certificates alike. So, certainly the costs for running OCSP are comparable in both cases. You could argue that CRLs cost a bit more, but largely only because of the bandwidth cost (as CRL is just a file).

Note again (and I pointed at this in my original reply): even now, BR contains no requirements on specific availability or latency beyond the original requirement (13.2.3 v1.0, 4.10.2 v1.4.5) that:

>>"The CA SHALL operate and maintain its CRL and OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions."

Ten seconds! Under normal operating conditions (DDOS survivability, ha!). Meeting requirements on the cheap is not the same as doing it right (to the extent that's even possible). And you are far to blasé about the growth of CRL in a situation where an unlimited number of 1 or 2 year length certs can be issued free of charge. One of the most principle rules of service scaling is that if you make something available that has a minor cost available at no cost, there is always a risk that users will fully take advantage of that.

One of the best parts about the new BRs is that they've started the process of allowing CAs to replace base OCSP requirements with use of Stapling (although oddly only for "high traffic" sites, whatever that means). That should be generalized/accelerated and both CRLs and base OCSP done away with entirely ASAP. But even given previous and existing rules I find your assertions that StartCom was dishonest or failed to meet requirements unconvincing right now.

----

1: http://web.archive.org/web/*/www.startssl.com

2: http://web.archive.org/web/20100704102024/http://www.startss...

3: https://cabforum.org/baseline-requirements-documents/