> That's right up there with "unintentionally loaded a gun, drove to the bank, held it up at gunpoint, and left with bags full of cash", and about as believable.
While I'd like it if it that were the case... did you see the PDFs that I linked elsewhere in this discussion thread, that CNNIC originally posted to mozilla.dev.security.policy?
https://pzb-public-files.s3-us-west-2.amazonaws.com/B2.pdf
I can see the following series of incompetences as entirely too plausible:
- MCS happens to have some multi-function Palo Alto devices, because they're reasonable devices to have for a network operator.
- Palo Alto ships real-time SSL MITM capabilities (i.e., loaded guns) in their products, because lots of customers want them for use with internal CAs.
- Palo Alto is also a FIPS-compliant hardware crypto device, because thanks FIPS.
- MCS and CNNIC both vaguely know that intermediate certificates should only be kept on FIPS-compliant hardware crypto devices. They don't know why, they just know it's what people do.
- MCS looks around, sees the Palo Alto device, decides it's the right sort of device to use, and clicks the "Generate a CSR" button and sends it to CNNIC.
In any case I certainly agree that this deserves CNNIC removal, even if everything CNNIC and MCS has said is true (they're both admitting to gross negligence that failed at the most basic tasks of a CA, even if there was no malice in a strict sense). And also deserves MCS or any suspiciously similar organization being blacklisted by all the other CAs if they come asking for an intermediate.
Like, if it weren't for the hardware crypto requirement, it sorta sounds like MCS would have happily run `openssl req` on some developer's machine, and CNNIC would have happily signed it with their globally-trusted CA cert. Which would not have set off Google's tripwires, but would also have been completely unacceptable.