back
19 comments
> However, several CAs disliked having to revoke all those certificates, because it cost them staff time (and hence money) to do so. They went so far as to change their procedures from the standard way of accepting problem reports (emailing a generic attestation of compromise), and instead required CA-specific hoop-jumping to notify them of compromised keys.

Maybe the baseline requirements need to be updated to require an automated mechanism for reporting key compromises. CAs have to revoke certs with compromised keys, but by going out of their way to increase the barrier to doing so, they're clearly not complying in good faith.

The ACME protocol (Let's Encrypt) makes this simple - just sign a request to the revocation API with the cert's private key.

I’m unsure what part of revoking certificates is labor intensive if you’re a certificate authority, given your entire purpose is to sign and revoke keys..
I get the impression that some of the big name CAs are ... not very technology oriented, you might say. They focus on the sales side, and treat the actual issuance and revocation of certificates as an unfortunate cost center and minimize investment.
I can imagine it's hard to convince a BA that they should invest in responding to requests from non-customers.
Most of their process is 100% automated. Revoking based on free-form reports would at the very least require a human to deal with the report.

Also, customer service for dealing with the certificate holder.

That said, offering an API and automating as much as they can is a lot easier than receiving the reports through free-form e-mail, with followup through Mozilla's root program (https://wiki.mozilla.org/CA/Bug_Triage#Compliance_Problems_a...), where the CA will have to take action or cease existing.

You need to notify the customer and then deal with the support work when they roll the key. Also they will get some blame from the customer for having to deal with the situation. All that without much extra payment. It's much more profitable to not care.
The CAs have automated signing and have zero labor in that part. Revoking is a manual process, infinitely more labor intensive.
>However, several CAs disliked having to revoke all those certificates, because it cost them staff time (and hence money) to do so. They went so far as to change their procedures from the standard way of accepting problem reports (emailing a generic attestation of compromise), and instead required CA-specific hoop-jumping to notify them of compromised keys.

It would have been nice to have names be named. This is obviously in bad faith, and the bad actors should be called out.

Given that Matt Palmer is an active participant of the MDSP (Mozilla Dev Security Policy) mailing list, I am surprised that I don't recall seeing discussion about this pop up, although I may have missed it. The CAs acting this way really should have to explain themselves.

So the Fediverse should blacklist those CAs.
WTF? CAs should be mandated to have an automated, public form/API where you can submit a private key to have it revoked.

Lets encrypt has this. https://letsencrypt.org/docs/revoking/#using-the-certificate...

The API for Let's Encrypt to do this requires possession of the private key, which pwned keys doesn't always have. Sometimes they just have an "attestation" of compromise:

https://pwnedkeys.com/submit.html

Which if you had an standardized representation of that attestation, maybe CAs could consume that instead.

But, the author of pwnedkeys thought of that, and started an RFC for exactly that:

https://github.com/pwnedkeys/key-compromise-attestation-rfc/...

But it seems dead right now.

> I stopped sending compromised key notifications to CAs. Instead, now I’m publishing the details of compromised certificates to everyone, so that users can protect themselves directly

If this is most feasible, ok, though it smells like the opposite of responsible disclosure. Perhaps I'm just not in tune with the nature of how this threat differs from a typical software vulnerability, and therefore the responsible disclosure method I'm familiar with is irrelevant.

> though it smells like the opposite of responsible disclosure

He's not sharing the key itself, just proof that it's been leaked. Unlike disclosing a security issue without warning, this disclosure doesn't give any bad actors and power they didn't already possess. (Because any bad actors who have the key would already know what TLS certs it matches, or could trivially find out by querying CT logs themselves.)

Even with the key, from what I can tell it’s fairly hard to exploit for the average netizen.
Thank you!
The surrounding text explains that several CAs didn’t like having to spend resources doing revocations and intentionally made the disclosure process more onerous.

Responsible disclosure is a courtesy that should not be extended to bad faith actors.

> If this is most feasible, ok, though it smells like the opposite of responsible disclosure.

Read: https://adamcaudill.com/2015/11/19/responsible-disclosure-is...

How are private keys identified as compromised? Is that a function of certificate transparency?
Gross Negligance