Hacker News new | ask | show | jobs
by AlyssaRowan 4145 days ago
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.

1 comments

> 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.