Also, why would ssl.com even create a subCA named "QuantumCA"? Are they in business with this person claiming to be the founder of "QuantumCA" who appears to be responsible for exploiting this acme.sh 0day? What does this say about ssl.com's trustworthiness? Or is the person in the github comments lying?
Correct. You can see the Quantum intermediates listed in ssl.com's most recent audit statement, meaning an auditor has verified that ssl.com has controls to protect the private key: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?at...
(The audit could be flawed, but it's the same amount of assurance we have for any intermediate CA's private key - the fact that "QuantumCA" is in the name does not change the risk calculus)
> Also, why would ssl.com even create a subCA named "QuantumCA"? Are they in business with this person claiming to be the founder of "QuantumCA" who appears to be responsible for exploiting this acme.sh 0day? What does this say about ssl.com's trustworthiness? Or is the person in the github comments lying?
There is a business relationship between QuantumCA and ssl.com. QuantumCA is a reseller of ssl.com, and they've paid extra to ssl.com so that the certificates they purchase get issued from an intermediate CA named "QuantumCA" rather than one of ssl.com's usual intermediate CAs which have "ssl.com" in the name. This lets QuantumCA pretend to be a real CA. This is a common practice in the industry, and I don't think it says anything about the trustworthiness of ssl.com, because the business relationship with QuantumCA doesn't in any way subvert the integrity of the WebPKI since ssl.com retains control of the issuance. Still, I wish intermediate CA white-labeling were banned because it causes terrible confusion about who is and isn't a CA.
So QuantumCA == HiCA == exploiters of the acme.sh 0day, it's all the same entity? The intermediate CA could just as well be named "0dayexploitersCA"? Why is it not a huge concern that ssl.com is fine with operating such a "0dayexploitersCA" intermediate?
Am I missing something here?
all CA requirements for validation still need to be fulfilled for issued certificates, as ssl.com, the Quantum CA operator, which exclusively holds the private keys, is a "proper" CA.
this does not affect the trust in the CA infrastructure or ssl.com itself; while this is morally questionable to keep the business relationship, it does not mean the CA is not following the signing requirements.