More details in the now-public bugzilla issue:
The plot thickens.
Broken HSM? Misconfiguration? Confusion? Straight up lie?
> Excel attached. The Ultimaco devices were used to generate the ECC, RSA key pairs for the issuers. They were not used to generate any other key material. But it doesnt look like the device is at fault.
> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
…
> The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys.
And THAT is where I'm drawing the line between "honest mistake" and "gross negligence". For that to not raise giant red flags is an unacceptable failure in process and work culture.
The theory was that someone misinterpreted 384-bit keys to mean the key must be a number between 1-384.
I think that's entirely made up, but it wouldn't be completely implausible to have happened while someone tried to troubleshoot why the first attempt failed.
The discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=2083449 really doesn't sound like that, but who knows what's getting lost in the "fog of war" we're currently getting on this all.
A language barrier is not an acceptable excuse, especially in a country where the primary language of technology firms is English.
Instead, I consider a lack of concentration due to too much stuff going on around to be a big factor.
The biggest problem when working with Indian offices is that their crew always has to deal with weird shit continuously that it would be extremely surprising for me to have someone fully concentrated on their work.
The whole point of a key ceremony is that you're not going off-script and YOLOing random crap.
What was more troubling was the other people involved couldn't understand why I did it.
https://utimaco.com/news/blog-posts/global-encryption-day-en...
Ah yes.
"The system says something is wrong, but it's also 4.30PM. Let's just re-sign the thing and go home."
Good luck recovering from this.
That seems like a WAY bigger problem than TLS, but AFAIK Windows still validates code signing certs against CRLs before trusting them (can't remember if it soft-fails).
This is absolutely false, it's a simple policy change to enforce code signing, any organization that is serious about security can do it.
I'll give you the benefit of the doubt and assume you're another Linux guy who doesn't understand Windows security.
The concern of course is with malware being signed, which is far more likely to be abused than some TLS MITM fantasy.
You already need compromised systems to install malware, signed or not. Not a real problem.
For TLS MitM you just need to use a shared network, wired or wireless.
Is this true? Ads pointing to a malicious Notepad++ is already an existing thing. Now their malicious version will pass signing checks. Users will happily install these without the system itself being compromised.